Handle single quotes in 'darling shell'

[bemoody]

If the command-line arguments to darling shell include single quotes, they must be escaped when constructing the string that is sent to shellspawn.

(Only single quotes need special handling; all other characters, including backslashes and control characters, are treated literally within single-quoted strings.)

For example, running the command

$ darling shell sh -c "echo 'hello world'"

would result in the following string being sent to the shell:

'sh' '-c' 'echo 'hello world''

(which is interpreted as a command with three arguments: "-c", "echo hello", and "world").

What we want instead is:

'sh' '-c' 'echo '\''hello world'\'''

(which is interpreted as a command with two arguments: "-c" and "echo 'hello world'".)

[HinTak]

Or put it in a file and run it? It is easier than piling on multiple escapes through multiple stages.

[HinTak]

The problem is that the argument is interpreted twice - by the host's shell then by darling running the darling version of shell. If you put the content in a file it is run by darling's version only.

You get the same problem on the host os by doing sh -c sh -c echo ...

[HinTak]

I don't think this should be merged - even the host shell does not support sh -c sh -c echo ....

[bemoody]

The problem is that the argument is interpreted twice - by the host's shell then by darling running the darling version of shell.

No, the problem is that darling adds single quotes around each argument, but doesn't escape single quotes within them. Let's step away from shell syntax, because it makes things confusing. Are you familiar with Python? In Python, you could write subprocess.call(["/bin/echo", "Here's an apostrophe!"]) and it would invoke the program /bin/echo with a single argument ("Here's an apostrophe!"), and /bin/echo would dutifully print that message to standard output. If you wanted to instead print the message using the Darling environment, you might try: subprocess.call(["darling", "shell", "/bin/echo", "Here's an apostrophe!"]) But that would fail, because of darling's incorrect quoting. Note that in this case, there isn't any "host shell" - the only shell involved here is the one that's used internally by "shellspawn". The problem here doesn't have anything to do with "sh". When you invoke a program using "darling shell", you expect the arguments you supply will be faithfully conveyed to the program on the other side. (Just as with, say, "env" or "nice".)

[bugaevc]

Makes sense to me.

even the host shell does not support sh -c sh -c echo ....

@HinTak But sh is not supposed to be invoked like sh command arg arg..., it's supposed to be invoked either as sh ./script.sh, or as sc -c "command arg arg..."

darling shell, on the other hand, is supposed to be invoked as darling shell command arg arg...; and what that does is it calls sh -c "'command' 'arg' 'arg' '...'" inside the container. We quote the arguments, so it makes sense to escape them properly.

[ahyattdev]

looks good to me @bemoody