On Sat, May 27, 2023 at 02:45:34AM +0200, Thorsten Glaser <t.glaser at
tarent.de> 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 at host ls -l "'a b'"
> > ssh user at host "ls -l a\ b"
>
> This one, incidentally, sends 'ls -l a b' to the remote shell.
> ssh user at 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 at host "ls -l 'a b'"
>
> But you could also just do:
> ssh user at 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!
>
****************************************************