What difference does ssh command quoting make?

Question

How is it that these commands result in different output?

⋊> ssh host bash -c \'cd /tmp; pwd\'
/home/manu
⋊> ssh host \"bash -c \'cd /tmp; pwd\'\"
/tmp         


        

Answer 1

The thing to understand here is that ssh simply concatenates its arguments (in the same way that $* does), and passes that concatenated string to sh -c.

---

Thus, in the case of:

ssh josh-play bash -c 'cd /tmp; pwd'

...ssh runs:

sh -c 'bash -c cd /tmp; pwd'

...thus, sh runs:

bash -c cd /tmp
pwd

...and as you can test yourself, bash -c cd /tmp doesn't do much that's useful (the script text it runs consists only of cd; /tmp is stored as an argument, but the script text never reads its arguments, making that moot). Moreover, as soon as bash exits, we're back in the parent sh process, in which cd was never run.

The syntactic quotes passed to your outer shell are entirely lost, and the pwd is invoked not by the bash that you manually triggered (which, in this usage, simply invokes cd without any arguments -- /tmp is in $1, but the script passed as an argument to cd never dereferences that variable) but by the sh that ssh implicitly invokes.

---

If you know that your remote sh is provided by bash or ksh -- a shell supporting the $'' extension -- you can do the following for any arbitrary argv array (in this case bash, -c, cd /tmp; pwd):

# ask your shell to generate an eval-safe quoted form of your argument list
printf -v rmt_cmd '%q ' bash -c 'cd /tmp; pwd'

# pass that through to be run by the remote sh -c
ssh josh-play "$rmt_cmd"

The caveat to the above is that if your argument list can contain newlines or hidden characters, printf %q in bash or ksh can escape it in a form that POSIX sh isn't guaranteed to be able to read. To avoid that:

# ask your shell to generate an eval-safe quoted form of your argument list
printf -v rmt_cmd '%q ' bash -c 'cd /tmp; pwd'

# ...and use bash to evaluate that quoted form.
ssh josh-play 'exec bash -s' <<<"$rmt_cmd"