On Sat, May 27, 2023 at 12:08:43AM +0200, Thorsten Glaser <t.glaser@xxxxxxxxx> wrote: > On Fri, 26 May 2023, Mingye Wang (Artoria2e5) wrote: > > > ssh(1) currently affords an argument-passing functionality, but as the manpage > > states, all arguments are simply concatenated by space. > > How else would it do that? The arguments are processed by the > shell first then passed as an array of NUL-terminated strings. > > > The modest proposal is that we put a giant CAVEATS section in the manual page. > > That might be useful indeed. I think that stating "all arguments are simply concatenated by space" is arguably clear enough, but it can be good to elaborate on even obvious implications. It can save time, especially with an example. So, perhaps this could be added to the existing sentence/paragraph: "so any spaces in individual arguments must be quoted using the syntax of the destination user's login shell". If an example were needed, something like these should make it clear: ssh user@host ls -l "'a b'" ssh user@host "ls -l a\ b" ssh user@host "ls -l 'a b'" Putting the extra information in a separate CAVEAT section is less helpful. I think it's better to put it where the feature itself is documented. People looking just for the documentation on that feature probably won't see the CAVEAT section at all. > > The less modest one is we throw out the "[argument ...]" part altogether. It > > Absolutely not. This will break about all uses of ssh in existence. > > > What about escaping the arguments? Nobody said the user has to use a POSIX > > Absolutely not. This will break almost all uses of ssh in existence. Not knowing the details of each user's login shell is precisely the reason that ssh couldn't ever do the quoting itself. Each shell is its own language with conceivably different quoting notation. The user knows what that language is because it's the shell they chose to use. ssh doesn't. It only knows the path to the login shell executable, and it hands the command over to the login shell to parse and execute. ssh is smart enough not to try to interpret the command itself in any way. Any attempt to do so would limit ssh's ability to execute arbitrary commands to only those that it can interpret. So the user has to do the quoting themselves. cheers, raf > bye, > //mirabilos > -- > Infrastrukturexperte • tarent solutions GmbH > Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ > Telephon +49 228 54881-393 • Fax: +49 228 54881-235 > HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 > Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg > > **************************************************** > /⁀\ The UTF-8 Ribbon > ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: > ╳ HTML eMail! Also, https://www.tarent.de/newsletter > ╱ ╲ header encryption! > **************************************************** > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
