It's hidden in the sense that it creates ambiguity at the usage site. Compare with sudo:
$ sudo ls 'file with spaces'
ls: cannot access 'file with spaces': No such file or directory
$ ssh example.com ls 'file with spaces'
ls: cannot access 'file': No such file or directory
ls: cannot access 'with': No such file or directory
ls: cannot access 'spaces': No such file or directory
$ ssh example.com "ls 'file with spaces'"
Accepting a shell string is sometimes OK, but silently joining multiple args is useless, and insecure.
"RTFM" is not a good answer when security is involved.
This stubborn attitude to refuse to consult the documentation at all and then expect the tool to work according to your preconceptions.
Tools do have rough edges, if you don't want to learn about them, you will get bitten.
This statement can be true without contradicting anything anyone said upstream. Otherwise could use it to justify just about any bad design decision.
Yes it’s in the docs. Yes people who carefully read the docs won’t get bitten. Also yes the design could be improved so people don’t make this mistake even without reading the docs.
Both things can be true. We’re currently only talking about the latter, though.
> We’re currently only talking about the latter, though.
I'm surprised, as i started this subthread explicitly to contest that the argv join is "hidden".
> Tools do have rough edges, if you don't want to learn about them, you will get bitten.
I presume you consider INTERCAL to be a sanely designed programming language.
I'm not defending SSH's design, im criticizing peoples unwillingness to learn about the design as it is so they can work around it.
Edit: The INTERCAL handbook is a great read, and despite being satirical, it is more detailed and qualified than the documentation of some other popular projects.
It’s a design mistake because it adds exactly zero functionality.
The only thing it adds is insecurity.
If the feature didn’t exist, then it wouldn’t need to be documented, and the world would be better.