remote command word splitting

frederik at frederik at
Thu Dec 2 09:19:28 EST 2004


I have a suggestion about the way ssh does word splitting on commands
which have been passed to it for remote execution. It appears that
what is currently done is, if there are extra arguments on the ssh
command line for a remote command, (1) split each of these arguments
into a list (2) concatenate the resulting lists to get the command
arguments. So we get behavior like

$ perl -le 'die "hi"'
hi at -e line 1.
$ ssh some-host perl -le 'die "hi"'
Died at -e line 1.

(The remote perl program executed differently because ssh split the
eval text into separate arguments) This is a gotcha that seems to come
up a lot for me. Many commands require arguments with spaces in them.
It's especially frustrating to try to operate through firewalls and
such by nesting ssh commands. Granted, working around this isn't
impossible - I just have to make sure that the command I run is only
one argument on the ssh command line, and that it's appropriately
quoted. But doing this is cumbersome and obscure, and I wonder why
it's necessary.

For instance, what if ssh had the following behavior: (1) if there is
a single argument, split it into a list of words, and use this list as
the remote command; (2) otherwise, leave the arguments as the user
specified them. This would fix my problems, and it would only cause
unintended consequences if the user wanted to run a remote executable
with spaces in its name (and with no arguments), which is a situation
that I've never encountered.

Also, importantly, I think this suggestion would be mostly backwards
compatible, although others might have a better sense of this. It
might not be wise to make it the default, since it would surely cause
*some* things to break, but I'm wondering if it would be worthwhile to
allow users to enable such behavior through, say, a configuration
variable. If people think it's a good idea, I can submit a patch.

Frederik Eaton

More information about the openssh-unix-dev mailing list