FR: Allow using environment variables (`${SHPOOL_SESSION_NAME}`) in `default_dir` config option

[sdoerner]

AI Policy Ack
Please read the AI policy in HACKING.md and ack that you've done so here.
Ack.
What new feature do you want?

I want to be able to use environment variables inside the default_dir setting, e.g.

default_dir = "/home/${USER}/scripts"

The main use case is to use the $SHPOOL_SESSION_NAME variable.

Why this is useful?
On my remote machine, I have a few different repositories that live under a common root (Think /home/$USER/coding/$repo). Using the local shell function approach, I can use work $repo to shpool into a re-usable session for that project. However, if that session does not exist, it currently starts at ~. I want to be able to set

default_dir = "/home/${USER}/coding/${SHPOOL_SESSION_NAME}"

in my settings so that newly-created sessions already start in the right directory.

[ethanpailes]

That seems like a reasonable feature. To implement this we'll need to thread down the initial shell environment to where we do the initial directory resolution, but they should be pretty close together in the code (all in the shell setup code) so that shouldn't be too bad.

One thing is that I would like to be more restrictive than traditional shell syntax. There should be exactly one way to perform environment variable substitution, and I think we should go with ${VARIABLE} (curly braces required). It's both easier to parse and conforms to what shell linters like shellcheck somewhat informally consider "shell strict mode."

One slightly complicating factor is that we actually have two different variable environments: the actual env vars, and the shpool variables. Currently shpool variables are accessed in templates with {VAR} so we could have {SHPOOL_VAR} and ${ENV_VAR}. That is slightly confusing, but I think it would be more confusing to not support shpool vars at all.

We do actually currently support shpool vars in --dir (https://github.com/shell-pool/shpool#templates) so that's one thing you can use today, but it is not quite the same thing as env vars and I'm not sure if it will work if you just put it in your config rather than passing on the command line (which is a bug we should probably fix if there is a mismatch). I think the env var resolution must happen daemon side and template resolution must happen attach proc side, so probably we need to just make sure that the config var is unified with the flag and then allow the dir string in the attach header to contain env var subsitutions that the daemon then resolves.

Are you interested in implementing this? I can give you some pointers to places in the code to start poking at if so.

[sdoerner]

Thanks for the --dir pointer. It is actually a totally adequate solution for my actual problem.

I can just construct the desired path inside my local shell function (manually) and pass it explicitly with --dir. I don't even need any variable substitutions.

Perhaps this FR is still useful anyway, to make this more convenient (or share this across different clients). But I think it means I don't care enough about it anymore to implement it.

[ethanpailes]

Sounds good. Let's leave this open since I think it is a good feature idea. Glad you have enough tools for your workflow!