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

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2563

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'
foo
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.