Hello, 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
frederik at a5.repetae.net wrote:> Hello, > > I have a suggestion about the way ssh does word splitting on commands > which have been passed to it for remote execution.ssh doesn't do splitting. You local shell does it and ssh just passes the result to a remote shell, which may do its own splitting.> 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.You local shell will be eating the outermost set of quotes before ssh touches it. If you explicitly quote your commandline, then you can avoid any problems: [djm at baragon djm]$ ssh djm@::1 "perl -le 'die \"hi\"'" hi at -e line 1. Maybe the way that ssh reconstructs the argument string to send to the server could be changed to insert quotes around arguments with spaces in them, but that would require ssh to examine the commands themselves. I don't think that this is acceptable because it means that ssh would magically muck with your command behind your back. I have no doubt that this would break people's scripts.> 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 defaultSorry, but we won't be adding different "modes" to modify the commandline - that is a useless knob when you can just quote it explicitly. -d
frederik at a5.repetae.net wrote:> $ 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)Not that this is really any help but seeing this discussion I thought I would throw this in. echo echo one two three | ssh some-host sh By using stdin to a shell I get two benefits. I always get the same shell regardless of the account's login shell. I have a more predictable, and to me easier to deal with, number of quoting layers that need to be done. YMMV and all of that. Bob