Using shell-words to split shell commands is weird

[CyberShadow]

Hi, thanks for creating shpool. This is more of a feedback ticket rather than a bug report, so feel free to close it.

What happened
I was surprised by the unusual behavior of the -c flag.

What I expected to happen
Usually, programs which accept another command to run do it in one of two ways:

1. A program name and a list of arguments. For example, docker and env work in this way.
2. A single string which is then passed to a shell's -c argument. Shells and ssh work in this way.

shpool does neither: it accepts a single string, but then only does one subset of the usual parsing that a shell would do. So, for example, ~ does not expand to $HOME, variables aren't expanded, and and piping / redirection doesn't work.

Since it's using a -c switch, I think the path of least surprise would be to do the equivalent of execv("/bin/sh", "-c", ...arguments...);.

To Reproduce
Steps to reproduce the behavior:
I think this is reproducible with something like shpool -c '~/bin/my_script'.

Version info
shpool 0.8.0

Logs
N/A

[ethanpailes]

Unfortunately, it's not so simple to do that. An importaint part of the semantics of -c is that the command is the root process run in the pty that shpool forks off, so it would be a problem if we always wrapped the command in /bin/sh -c ... since then there would be another process in between shpool and the command process. This would have implications for how things like environment variable resolution works.

That said, I do understand the pain-point. It would be nice if ~ expanded to the user's home dir (this one is relatively easy since it can be done without reference to environment variables). $ENV expansion would also be nice, but there is a pretty big snag there. Normally, the user's shell environment gets set up by their init scripts, but by neccecity the command is invoked before their shell starts up. This means they could refernece variables defined in /etc/environment and thats about it. I'm not sure it's worth supporting when users would only have access to such a limited list of env vars they could expand.

I suppose what we could do is do the resolution in the shpool attach process where env vars are already populated, but that is already possible today by just doing `shpool attach -c "/path/to/cmd $ARG_FROM_ENV $ARG_FROM_ENV2" (note the double quotes). I honestly think it would be more supprising if single quotes resulted in local variables being expanded since that violates all the normal rules of the shell.

Probably the right thing to do is to resolve ~ but leave env vars untouched, allowing users to resolve them or leave them unresolved using normal shell semantics.

[CyberShadow]

In that case, I would suggest making -c act more like a separator, which can be followed by the rest of the command as its own arguments. This is what e.g. nix develop does.

This would have implications for how things like environment variable resolution works.

I'm curious what you mean by this. It is generally accepted knowledge that, beyond the obvious invocation distinctions, execvp and system will generally behave identically. The distinction can be reduced further by prefixing the shell command with "exec ".

Probably the right thing to do is to resolve ~ but leave env vars untouched, allowing users to resolve them or leave them unresolved using normal shell semantics.

For what it's worth, I strongly disagree that this is the right thing to do. It makes the behavior even more custom, unpredictable, difficult to understand.