Re: -e escape rule

On 11/20/2016 02:55 PM, francis.montag...@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

Re: -e escape rule

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

Re: -e escape rule

> 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

Re: -e escape rule

On Sat, Oct 29, 2016 at 5:36 AM, Samuel Williams < space.ship.travel...@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

Re: -e escape rule

> The point is that the original escaping DOUBLE escapes an equals sign: > foo\\\=bar > It shouldn't, there's no reason to. If you paste into your command line: rsync -e ssh\ -l\ backup\ -i\ /etc/synco/id_rsa\ -o\ ConnectTimeout\\\=60\ -o\ BatchMode\\\=yes The list of arguments would be (i.e.

Re: -e escape rule

On Sat 29 Oct 2016, Samuel Williams wrote: > I'm not proposing some additional characters to split on, but quite > the opposite, to handle the backslash escaped spaces correctly and NOT > split. Rest assured, there is no bug with the original escaping. For > your edification: > > $ echo \I\'\m\

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: -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: -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

Re: -e escape rule

Hmm, so after reviewing this in a bit more detail.. it would be very nice if at least backslash escapes would be supported. Quoted strings are pretty ugly, especially when nested several levels. Anyway, just my 2 cents. -- Please use reply-all for most replies to avoid omitting the mailing list.

Re: -e escape rule

Hi Dave, thanks for point that out. I didn't realise there was a detailed explanation of that field in the man page, I only saw the summary. Yes, that clearly explains how it's supposed to work. On 21 October 2016 at 01:46, Dave Howorth wrote: > On 2016-10-20 10:24,

Re: -e escape rule

The \ escapes are for the shell. Rsync never sees them and therefore can't honor them. On 10/20/2016 05:24 AM, Samuel Williams wrote: > Hello, > > I'm using Ruby's Shellwords module, which generates a string from an > array, suitable for shell evaluation. > > Ruby's implementation prefers

Re: -e escape rule

On 2016-10-20 10:24, Samuel Williams wrote: Hello, I'm using Ruby's Shellwords module, which generates a string from an array, suitable for shell evaluation. Ruby's implementation prefers escaping whitespace with a backslash rather than quotes. However, this appears to cause some kind of issue

Re: -e escape rule

> There's no reason to escape an "=" sign in the above command. Okay, so at a certain level I agree with you and that's how I've fixed the issue. All the stuff about config files is not feasible for a variety of reasons - I'm aware of those options. I appreciate that you took the time to explain

Re: -e escape rule

On Thu 20 Oct 2016, Samuel Williams wrote: > > I'm using Ruby's Shellwords module, which generates a string from an > array, suitable for shell evaluation. > > Ruby's implementation prefers escaping whitespace with a backslash > rather than quotes. However, this appears to cause some kind of