On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser@xxxxxxxxx> wrote: > On Sat, 27 May 2023, raf wrote: > > >So, perhaps this could be added to the existing > >sentence/paragraph: > > > > "so any spaces in individual arguments must be > > Must they? No, a single space will do just fine. They do if you want the receiving shell to not interpret the space as a separator between arguments. > > quoted using the syntax of the destination > > user's login shell". > … keeping in mind the source shell’s quoting as well. > > >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" > > This one, incidentally, sends 'ls -l a b' to the remote shell. > ssh user@host "ls -l a\\ b" > has the effect you want; the first backslash is eaten by the > local shell. Perhaps that depends on the local shell. It works with zsh. Testing with dash would probably be better. That works too. I think you might be wrong. I think the slash would only be eaten by the local shell if it weren't inside doublequotes. > > ssh user@host "ls -l 'a b'" > > But you could also just do: > ssh user@host ls -l \'a b\' > > Only if it’s more than one space, or different whitespace, > does this come into effect. That wasn't one of my examples. That wouldn't work for a file "a b", as you say. > The more important point is things like pipes and redirections anyway. For them, the entire command needs to be quoted. > >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 > > Perhaps, perhaps not. Too much information in one place might have > the opposite effect. I’d rather give a short line there, with a > reference to .Sx CAVEATS below. Yes, as long as it explicitly refers the reader to CAVEAT. > >Not knowing the details of each user's login shell is > >precisely the reason that ssh couldn't ever do the > > Yes, exactly. > > But for… > ssh remhost ls -l \>foo > > … it MUST NOT quote the I/O redirection sign, otherwise > the redirection would not work. That’s why I’m saying it > needs not and must not quote. The redirecton sign isn't a space. We're talking about spaces. But the redirection does have to "quoted" locally otherwise it would apply to the local process, but it would need to be quoted like this: ssh remhost "ls -l >foo" > bye, > //mirabilos (current developer of a POSIX-compatible shell) > -- > 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
