https://bugzilla.mindrot.org/show_bug.cgi?id=2563
Pascal Bourguignon <[email protected]> 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 <[email protected]> --- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
