2 ms·

The key takeaway here is that the SSH client doesn't quote the arguments that constitute the command line when it transforms an argument vector to a string, whi

The key takeaway here is that the SSH client doesn't quote the arguments that constitute the command line when it transforms an argument vector to a string, which might be rather unexpected. Why the "exec" SSHv2 request only takes a string and not a vector of strings is anybody's guess. Perhaps for Windows compatibility, perhaps because the data representation used for the SSHv2 protocols didn't have a variable-length array syntax (though what would've been wrong with a "string cmdline" where each arg is separated by a NUL?).

hawski 5y ago
When I first encountered the behavior I thought it was a lazy bug. I was and still am baffled.
- chubot 5y ago
  Shell's 'echo' and 'eval' have the same issue. They just dumbly concatenate their arguments with a space! In https://www.oilshell.org https://www.oilshell.org, the simple_echo and simple_eval_builtin options make it so that echo and eval accept ONLY one argument. This means you have to use this style: echo $x $y # illegal echo "$x $y" # allowed since it's a single argument write -- $x $y # legal and respect explicit separator There's a separate "write" builtin that is more sane because we avoid changing the behavior of existing builtins, even when there is an option set. This is also illegal when there's word splitting, but Oil doesn't have it (it turns on simple_word_eval [1] and simple_echo_builtin at the same time): echo $x This ssh behavior is probably of the same vintage. Since it's an external comand, the best we could do it wrap it with "myssh" or something similar, which doesn't have this pitfall. [1] http://www.oilshell.org/blog/2021/04/simple-word-eval.html http://www.oilshell.org/blog/2021/04/simple-word-eval.html
  - deleted 5y ago
    [deleted]
bombcar 5y ago
It likely wasn’t considered and now changing it would break many things.
nerdponx 5y ago
It looks like it's done this way on purpose to prevent the SSH client from bypassing restrictions imposed on the user's login shell.

hawski 5y ago

When I first encountered the behavior I thought it was a lazy bug. I was and still am baffled.

chubot 5y ago
Shell's 'echo' and 'eval' have the same issue. They just dumbly concatenate their arguments with a space! In https://www.oilshell.org https://www.oilshell.org, the simple_echo and simple_eval_builtin options make it so that echo and eval accept ONLY one argument. This means you have to use this style: echo $x $y # illegal echo "$x $y" # allowed since it's a single argument write -- $x $y # legal and respect explicit separator There's a separate "write" builtin that is more sane because we avoid changing the behavior of existing builtins, even when there is an option set. This is also illegal when there's word splitting, but Oil doesn't have it (it turns on simple_word_eval [1] and simple_echo_builtin at the same time): echo $x This ssh behavior is probably of the same vintage. Since it's an external comand, the best we could do it wrap it with "myssh" or something similar, which doesn't have this pitfall. [1] http://www.oilshell.org/blog/2021/04/simple-word-eval.html http://www.oilshell.org/blog/2021/04/simple-word-eval.html
- deleted 5y ago
  [deleted]

bombcar 5y ago

It likely wasn’t considered and now changing it would break many things.

nerdponx 5y ago

It looks like it's done this way on purpose to prevent the SSH client from bypassing restrictions imposed on the user's login shell.