-e escape rule

[Samuel Williams]

> assuming that a shell is being used is invalid

I 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-zero

Well, 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..
>