openssh unix dev - Oct 2018 - The first command of a nested compound command receives no arguments

On Sun, Oct 21, 2018 at 07:30:44PM +0200, Gert Doering
wrote:
> On Sun, Oct 21, 2018 at 10:21:56AM -0700, Parke wrote:
> > On Sun, Oct 21, 2018 at 3:32 AM Timo Kilpilehto <timo at
kilpilehto.fi> wrote:
> > > eval sh -c "echo none of this makes any difference"
> > 
> > Where is it documented that ssh is going to eval my command?  The fact
> > remains that ssh does not transparently pass the command to the remote
> > host.
> 
> This is not a *ssh* thing, but a generic "how does quoting on unix
work
> if two levels of shell are involved".
This is an oversimplification.  It's an SSH thing to the extent that the
SSH protocol defines that command execution is done by passing a single
command string, the ssh client specifically joins its arguments using
spaces in order to send them to the server, and the ssh(1) manual page
doesn't explain what's going on at all.

There are of course limits to how much it can nail down, because the
exact behaviour depends on the remote user's shell; but the
documentation could at least explain that the client joins any
command-line arguments following the destination using spaces and sends
them to the server as a single string, which can then generally be
expected to pass them as an argument to "sh -c".  People who
aren't
especially familiar with the details of the SSH protocol but who are
using ssh as a building block would then have a better chance of working
out what quoting they need to use.

In general, it's a very good idea for commands that can invoke
subsidiary commands to document the quoting requirements even if they're
straightforward, as they're often non-trivial and the consequences of
getting quoting wrong can be unfortunate.

The protocol-level part of this is
https://bugzilla.mindrot.org/show_bug.cgi?id=2283.

-- 
Colin Watson                                       [cjwatson at debian.org]

On 2018-10-21, Colin Watson <cjwatson at debian.org> wrote:
> This is an oversimplification.  It's an SSH thing to the extent that
the
> SSH protocol defines that command execution is done by passing a single
> command string, the ssh client specifically joins its arguments using
> spaces in order to send them to the server,
That behavior was inherited straight from rsh(1), which was really
just a wrapper around rcmd(3).  This whole thing goes back to 1982.
https://svnweb.freebsd.org/csrg/usr.bin/rsh/rsh.c?view=log

Nowadays people may not be aware that one of the selling points of
ssh was that it was a drop-in replacement for rsh/rlogin/rcp.

-- 
Christian "naddy" Weisgerber                          naddy at
mips.inka.de

On Sun, Oct 21, 2018 at 1:42 PM Christian Weisgerber <naddy at
mips.inka.de> wrote:
> Nowadays people may not be aware that one of the selling points of
> ssh was that it was a drop-in replacement for rsh/rlogin/rcp.
Even if people are so aware, the behavior itself is not documented in
the FreeBSD, Linux, or OpenSolaris rsh manpages.

Cheers,

Parke