> assuming that a shell is being used is invalidI never made this assumption. I looked directly at the source code and I stated that "I feel that this function should also handle backslash escapes." I think the assumption that splitting the command works the same way as (all?) major shells, is not inappropriate given the circumstances, and it seems like you agree.> but probably non-zeroWell, I understand where you are coming from. You don't want to break existing code. The work-around is to use quotes to escape the white-space sequence. It's okay.. But it's also a surprise that backslash escape sequences don't work according to intuition of how commands are normally executed. If you supplied the string in -e to system, it would work as expected.. Unfortunately, this is the default when using Shellwords.join in Ruby. So, I had to write a custom RSync "join" function to produce an appropriate command for -e argument. On 30 October 2016 at 04:49, Wayne Davison <wayned at samba.org> wrote:> On Sat, Oct 29, 2016 at 5:36 AM, Samuel Williams > <space.ship.traveller at gmail.com> wrote: >> >> The command >> >> ssh -l backup -i /etc/synco/id_rsa -o ConnectTimeout\=60 -o BatchMode\=yes >> >> Is a correct and valid shell command. > > > It is, but there is no shell involved, and assuming that a shell is being > used is invalid. Adding backslash escaping now could potentially screw up > anyone currently passing a backslash in their existing rsync scripts (a > small group of people, but probably non-zero). It's tempting to go ahead and > do this, but I think I'll just leave it as it is. > > If you want to work around that buggy escaping library, you could change > "ssh" to "ssh-nobs" and put the following into that file: > > #!/usr/bin/perl > exec 'ssh', map { s/\\(.)/$1/g; $_ } @ARGV; > > That adds backslash removal on the way to the ssh. It does not allow you to > backslash escape spaces, though, but someone could extend the script to > support that. > > ..wayne.. >
Hi On Sun, 30 Oct 2016 20:06:00 +1300 Samuel Williams wrote:> But it's also a surprise that backslash escape sequences don't work > according to intuition of how commands are normally executed. If you > supplied the string in -e to system, it would work as expected..> Unfortunately, this is the default when using Shellwords.join in Ruby. > So, I had to write a custom RSync "join" function to produce an > appropriate command for -e argument.I guess you are building from ruby a single string for the whole rsync command, and that you give it to the system ruby command. If this is it, it would be simpler to build instead an array of strings and to call system with this array as arguments. This way, ruby will call directly rsync without calling an extra shell and you will not have to re-quote the arguments, in particular the one for -e. Francis
On 11/20/2016 02:55 PM, Francis.Montagnac at inria.fr wrote:> Hi > > On Sun, 30 Oct 2016 20:06:00 +1300 Samuel Williams wrote: > >> But it's also a surprise that backslash escape sequences don't work >> according to intuition of how commands are normally executed. If you >> supplied the string in -e to system, it would work as expected.. >> Unfortunately, this is the default when using Shellwords.join in Ruby. >> So, I had to write a custom RSync "join" function to produce an >> appropriate command for -e argument. > I guess you are building from ruby a single string for the whole rsync > command, and that you give it to the system ruby command. > > If this is it, it would be simpler to build instead an array of > strings and to call system with this array as arguments. > > This way, ruby will call directly rsync without calling an extra shell > and you will not have to re-quote the arguments, in particular the one > for -e. > > Francis >A couple of years ago I was having somewhat similar problems building an rsync command in bash and someone on this list suggested exactly the same solution. It really makes things simpler - and easier to read/maintain. Joe