ssh "bash -c" bug

[Phil Pennock]

I almost didn't send this, to avoid bothering the list, since the first
three paragraphs of my reply text below don't fix anything for ssh;
there's just enough value left that I'm sending anyway, but I'm unlikely
to waste everyone's time by responding further since I think I've made
my point.

On 2013-02-21 at 15:05 +0100, Peter Stuge wrote:
> 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.

> 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 on the widely-used shell I have been
using for 18 years and am more than familiar with the various forms of
quoting it offers.

Heck, I've even added features to it (zsh) for bash compatibility to
ease problems caused by folks using simple ssh recipes they don't fully
understand.

ssh takes some command and runs it on a remote host.  It is taking an
argument vector to be run.  It does not protect the individual
parameters and instead joins them naively with just a single space
between them, flattening argv badly.

It's far too late to fix it, but it's still both different and broken;
the OP's expectations were sane.  Bob proposed work-arounds which are
sane for people to take to avoid having to learn the precise ways in
which ssh is buggy and that's a good thing.  With his work-arounds,
folks client code is robust and understandable.  Avoiding a good
solution for one which demonstrates intimate protocol knowledge is a
questionable trade-off to demand of others, and will lead to more
fragility in practice as code has to be maintained by people of varying
skill levels:.

It's good practice to set up programming styles of handling something
which are hard to break, even when well-intentioned people try to fix
something that looks broken.  Adjusting your coding approach to
something that's easier to maintain and easier to protect is a sign of
Bob's apparent experience in dealing with real world script maintenance.

Maintainability trumps ego in showing off what you know.

Regards,
-Phil