Re: -e escape rule

> Yeah, it only does space-splitting and that's all it will ever do. It still > looks to me like there is a bug in the original escaping, since any command > receiving that string is receiving a backslash that is not supposed to be > there. It should only be escaping the string enough to get it

Re: -e escape rule

Kevin, I agree with what you are saying on some level, but I don't think the code does what you think it does. rsync -e "foo\\ bar" will be executed by the shell and yield a cmd string in the do_cmd function of "foo\ bar". This will be split incorrectly into an argv of ["foo\", "bar"]. I'm not

Re: -e escape rule

A \ is a shell escape. Every level of shell consumes one level of escape. For every session of a shell every example "\ " becomes " " and every example of "\\" becomes "\". The raync command line is a mix of local shell commands + commands run via a remote shell via ssh. The simple fact is

Re: rsync send "non-rsync" options to the server side (--remote-option) and (--protect-args)

If you want to pass non-rsync args (etc) you should be using --rsync-path. The -M option is only for sending rsync-related options. ..wayne.. On Fri, Oct 28, 2016 at 7:32 AM, John Lane wrote: > > Hello, I asked the below back at the beginning of August but have > received no

Re: -e escape rule

On Fri, Oct 28, 2016 at 5:39 AM, Samuel Williams < space.ship.travel...@gmail.com> wrote: > Rsync passed the backslashes through without dealing with them. > Yeah, it only does space-splitting and that's all it will ever do. It still looks to me like there is a bug in the original escaping,

Re: rsync send "non-rsync" options to the server side (--remote-option) and (--protect-args)

Hello, I asked the below back at the beginning of August but have received no replies. If anyone can help me with this problem it would be much appreciated. If I have not provided some necessary information then please let me know so I may do so. Thanks in advance. > I have been working on a

Re: -e escape rule

Wayne, I guess if you apply standard shell escaping logic you end up with a string which isn't processed correctly, yes, ssh complains, but only because Rsync passed the backslashes through without dealing with them. My opinion is that if Rsync is splitting a string based on whitespace it also