ssh "bash -c" bug

[Peter Stuge]

Phil Pennock wrote:
> > > > > Instead of confusing shell quoting I recommend piping the commands
> > > > 
> > > > ..must..avoid..learning..
> > > 
> > > The OP's shell quoting was absolutely correct,
> > 
> > The quoting was obviously NOT correct because things didn't work as
> 
> Quoting part of a reply to treat it out of context and attack something
> I didn't say is an interesting approach to civilised discourse.

I'm very sorry if you feel that I attacked what you said - my point
is that since the quoting didn't accomplish what was intended it
can't really be considered correct in the grand scheme of things.

I know that you meant that the quoting was correct in the *first*
shell. The while problem is that successful use of sh -c or a remote
equivalent requires taking care of *every* layer, not only the first.


> > ssh is a shell, not a command wrapper. Please just learn how your
> > shell's quoting works and reap the benefits of that instead of
> > resisting something because it doesn't fit into a certain pattern.
> 
> Please note: I have commit-bit

Yes, yourself and Bob both know quoting. The "you" I used was the
indeterminate third person, recommending them not to settle for
avoidance and encouraging them to learn more.


> ssh takes some command and runs it on a remote host.  It is taking
> an argument vector to be run.

But [command] in man ssh looks like a single argument to me, and the
man page doesn't mention anywhere that arguments will be
concatenated, so that behavior seems almost accidental. Of course I
also use it, and it's a handy optimization for the common case, but
I wouldn't mind terribly if OpenSSH changed to always use only the
first argument as the channel command.


> It does not protect the individual parameters and instead joins
> them naively with just a single space between them, flattening
> argv badly.

Comparing documentation to expectation I don't think that ssh is
doing anything wrong. The concatenation seems to be a perk, so I
don't think it makes sense to complain about it. The documented
syntax seems to be a single argument, which makes perfect sense
considering the protocol on the wire, which I guess was inspired
by how -c works for local shells (by way of rsh).


> It's far too late to fix it, but it's still both different and broken;

I don't see how it's different from sh -c (except that ssh optimizes
away that one level of quoting in the common case, which might actually
be doing new users a disservice) and I don't agree that it's broken.


> the OP's expectations were sane.

Again I disagree, especially considering the man page and how -c
works with local shells.


Follows a more philosophical - but still interesting - discussion.
Feel free to reply off the list!

> Bob proposed work-arounds which are sane for people to take to
> avoid having to learn

Yes! However I strongly disagree that avoiding learning about details
(maybe especially those that some consider to be bugs!) is a good thing.

More people should learn about more details, not avoid them.


> Maintainability trumps ego in showing off what you know.

It's not about ego - it's about efficiency and about preempting
problems by noticing them before the fact. Does such ability
boost ego? Sure. Is that a bad thing? I don't think so.

Do you honestly prefer lower efficiency and merely being reactive?

Why settle for mediocre like that?

It scales better, but why not promote excellence as part of scaling
up? No time? Of course it's safer not to, but I think that's a dead
end for the entire organisation. A negative spiral, instead of a
positive one.


I've programmed C for decades and I am always equally grateful when I
come across someone's code which makes me learn something new. That
happens only rarely now, just once in the last years, and admittedly
it was "just" a GCC extension, but anyway I think it is absolutely
fantastic to learn that way - discovering knowledge as a side effect,
while actually on a path of doing something else.

The cost of learning the constraints of that new thing is usually
low, although of course a more complex topic like shell quoting or
regular expressions can take years to master.

I think those techniques are still very much worth learning. It's
not like multiple levels of shell quoting is useful only with ssh.


On a more general note I find it depressingly common for people to
resist learning about layers below where they primarily operate,
depressing because it would allow them to make the most of the tools
at hand. I like to argue for "learning down the layers", and there
are often people who fiercely resist the mere idea.. Sad face.


//Peter