Feature request: Inherit CWD and runtime environment

[pbsds]

I love this. shpool is simple and really close to what I've been looking for.

Quite often however, I want something simple to prefix my commands with so I can reattach to it should I lose my connection or by accident close/crash the terminal emulator. With this in mind I find that shpool has two shortcomings:

1. --cmd only accepts a single string and not a list of strings, meaning the caller has to escape their command.

   Tools like xargs and pueue accept a list of strings which it simply joins with a space, optionally escaping each part first.

2. shpool runs the command without inheriting the current working directory nor the runtime environment variables, meaning such has to be re-established before the command can be run.

This is my current workaround in bash:

run_in_shpool() (
    TMP_ENV_FILE="$(mktemp)"
    { 
        declare -p # this one is overkill. Remove it if you don't need support for local bash variables, arrays and functions
        export -p 
    } >"$TMP_ENV_FILE"
    local uid="$(date '+%Y-%m-%d-%H:%M:%S')"
    set -x
    shpool attach "session-$uid" -c "bash -ilc \"source ${TMP_ENV_FILE%Q} 2>/dev/null; cd ${PWD%Q}; ${*@Q}\""
)

run_in_shpool echo foo bar baz

related:

• shpool session creates with pwd as home directory not on curent path #47 (touches on half of shortcoming #2)

[ethanpailes]

Since --cmd can be passed as an option in front of the positional argument, correctly handling multiple args to the flag seems potentially a little wonky. Since we use clap as and arg parsing framework, I don't know that we can implement custom parsing logic for command line flags. We could do a flag that can be specified multiple times, but shpool attach -c mybinary -c firstarg -c secondarg session-name feels rather weird. Just looking at that I think I would expect each -c switch to add a new command to be invoked one after another rather than them all getting glommed together into a single command line.

The contortions you are having to go through to forward the environment are another story. It's been brought up before, but we were waiting for a good usecase to be articularted. The machinery to forward the whole environment is mostly already there, so we would just need to either extend forward_env to accept a bool as well as vector of strings (not sure if we can do that in a backwards compatible way with the toml parser we use), or just add a new config field called forward_entire_env or something like that. If you want to take a swing at implementing that, I'm happy to drop some links in this thread to point you where to get started pulling. It should be a fairly straightforward change (possibly all in the client since all the machenery is built in the daemon to handle the limited list for forward_env).

Alternatively, if your scripts depend on a small well-known set of env vars, you could just use the existing forward_env feature. Probably not great for oneoffs, but if you are using this for more standardized tasks I could see an argument for always running with a standard and well-defined environment.

[ethanpailes]

#271 adds the ability to inherit CWD