6 ms·

But you could expect ssh localhost sh -c 'cd /tmp && pwd' to pass "sh -c 'cd /tmp && pwd'" over the network, which would trigger the expected behavior. Bu

But you could expect ssh localhost sh -c 'cd /tmp && pwd' to pass "sh -c 'cd /tmp && pwd'" over the network, which would trigger the expected behavior. But the arguments are not quoted so you end up with just: "sh -c cd /tmp && pwd".

vbernat 3y ago
It's because SSH sees "localhost" "sh" "-c" "cd /tmp && pwd" and will send "sh -c cd /tmp && pwd", which the remote shell will interpret as executing "sh" "-c" "cd" "/tmp" and executing on success "pwd".
mst 3y ago
Remembering to write ssh localhost sh -c "'cd /tmp && pwd'" works but (a) ICK (b) I usually only remember this on about attempt three at the earliest.
- rascul 3y ago
  ssh will read commands from stdin so this will work: echo "cd /tmp && pwd" | ssh localhost Or with a here string that bash and a few others support: ssh localhost <<<"cd /tmp && pwd" I often use the here string method. Maybe one of those would be easier to remember.
  - mst 3y ago
    Oooh, the here string reads nicely to me and would require less thought about quoting/interpolation choices which is a win on its own even if it still takes me multiple attempts to remember to do that. Much appreciated.
janosdebugs 3y ago
The problem is that the quote signs are already eaten by your local shell. The SSH binary gets the parameters like this: ['sh', '-c', 'cd /tmp && pwd'] How should SSH know what shell is running on the other end and escape it properly? Will it escape for Sh? Bash? Fish? Powershell? Python shell? Custom script? The SSH client would need to know what shell is running on the other end, which it can't. The server, which knows what will run, cannot fix this because it only gets the already mangled string. This is not solvable the way the protocol currently works because you can't support all possible constellations of client/server applications and shells.
- btilly 3y ago
  This. Exactly this. Rule 5 of http://cr.yp.to/qmail/guarantee.html http://cr.yp.to/qmail/guarantee.html remains completely true. Don't parse. When you try to use a user interface as a command interface, you have to parse. And some day it will bite you. The solution is to remotely invoke programs designed for the purpose, and then pass data to them in a structured format.
- Joker_vD 3y ago
  By the way, I had to use Powershell over ssh a couple of times (don't ask) and it works perfectly fine.

vbernat 3y ago

It's because SSH sees "localhost" "sh" "-c" "cd /tmp && pwd" and will send "sh -c cd /tmp && pwd", which the remote shell will interpret as executing "sh" "-c" "cd" "/tmp" and executing on success "pwd".

mst 3y ago

Remembering to write ssh localhost sh -c "'cd /tmp && pwd'" works but (a) ICK (b) I usually only remember this on about attempt three at the earliest.

rascul 3y ago
ssh will read commands from stdin so this will work: echo "cd /tmp && pwd" | ssh localhost Or with a here string that bash and a few others support: ssh localhost <<<"cd /tmp && pwd" I often use the here string method. Maybe one of those would be easier to remember.
- mst 3y ago
  Oooh, the here string reads nicely to me and would require less thought about quoting/interpolation choices which is a win on its own even if it still takes me multiple attempts to remember to do that. Much appreciated.

janosdebugs 3y ago

The problem is that the quote signs are already eaten by your local shell. The SSH binary gets the parameters like this: ['sh', '-c', 'cd /tmp && pwd'] How should SSH know what shell is running on the other end and escape it properly? Will it escape for Sh? Bash? Fish? Powershell? Python shell? Custom script? The SSH client would need to know what shell is running on the other end, which it can't. The server, which knows what will run, cannot fix this because it only gets the already mangled string. This is not solvable the way the protocol currently works because you can't support all possible constellations of client/server applications and shells.

btilly 3y ago
This. Exactly this. Rule 5 of http://cr.yp.to/qmail/guarantee.html http://cr.yp.to/qmail/guarantee.html remains completely true. Don't parse. When you try to use a user interface as a command interface, you have to parse. And some day it will bite you. The solution is to remotely invoke programs designed for the purpose, and then pass data to them in a structured format.
Joker_vD 3y ago
By the way, I had to use Powershell over ssh a couple of times (don't ask) and it works perfectly fine.