4 ms·

> This works: ssh host -- ls "folder\ name" > This also works: ssh host -- ls \"folder name\" Uh, why not ssh host -- ls '"folder name"' ? Single qu

> This works: ssh host -- ls "folder\ name" > This also works: ssh host -- ls \"folder name\" Uh, why not ssh host -- ls '"folder name"' ? Single quotes are the shell’s ultimate bulk “no touchy” escape, so if you don’t need them in the inner command, it seems easier to use them for everything. (Also when passing programs to sed, awk, jq, xmlstarlet, etc.)

jchw 3y ago
I believe that also works, but I don't do it often because I often wind up wanting to be able to use variables from the host, especially e.g. in cron jobs and scripts.
- mananaysiempre 3y ago
  Yes, that’s a valid thing to want. At that point, though, I’d try to write a general shell escaping function, because I don’t trust myself to figure out which host things are OK to include unescaped in such a situation. (Here’s when I start to long for Tcl, despite all the times I’ve had to spell out [string index ...].) The optimal solution would be to have a separate side channel for passing things to the quoted program, like -v in awk or --arg in jq (or whatever it is in your favourite SQL DBMS binding) but I don’t think SSH will let you do that.
nneonneo 3y ago
If you do need single quotes in the inner command, you can use the "'" trick: ssh host -- ls "'"'folder$name'"'"
- me-vs-cat 3y ago
  $name will never be expanded. Is that what you expected?
  - nneonneo 3y ago
    Yes, that’s the intent: using single quotes at both levels will prevent either your shell or the remote shell from expanding the name, so you can interact with a file name containing a literal $.
theK 3y ago
On another note, avoiding having paths with troublesome chars in them on servers does generally make the sailing much more pleasurable.