[Bug 2563] ssh bash -c drops arguments of the first command send to the remote.

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Fri Apr 8 21:51:09 AEST 2016


Pascal Bourguignon <pjb at informatimago.com> changed:

           What    |Removed                     |Added
            Version|6.9p1                       |7.2p1
           Severity|major                       |enhancement
                 OS|Linux                       |All
           Priority|P5                          |P3
           Hardware|ix86                        |All

--- Comment #2 from Pascal Bourguignon <pjb at informatimago.com> ---
You're right, the documentation specifies a single argument for the
command, so we can't say it's a bug.

Then let's transform this into a feature request/enhancement, to
upgrade the syntax to:

   ssh ... [command [arguments...]]

to match the behavior of su and sudo, amongst other commands.

That said, it could be argued that eg. sudo also takes [command],
without documenting it accepting arguments, but it accepts them and it
processes them as expected:

$ sudo bash -c 'echo foo;echo bar'

If [command [arguments...]] wasn't documented and implemented, I would
move to signal an error when giving superfluous arguments (both to ssh
and sudo, and any other such command not documenting what it accepts).

There's an argument to be made for using only [command] for sudo, ssh
and the like (even su): shell expansions are dones in the caller shell,
so if we don't use a single command-and-argument parameter, we have
more risks of issuing "not-what-I-mean" commands such as:

    ssh $remote ls *

But again, if we take this argument and reject [command
[arguments...]], then it would be better for the user (and less risky)
to signal an error for such a command.

You are receiving this mail because:
You are watching the assignee of the bug.

More information about the openssh-bugs mailing list