On Fri, Oct 28, 2016 at 5:39 AM, Samuel Williams < space.ship.traveller at 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, 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 to rsync, not trying to guess what rsync is going to do with it after it gets it. To work around that bug, you could consider using an ssh-calling shell script instead of manually specifying the ssh command and args to rsync. ..wayne.. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20161028/2a3905e3/attachment.html>
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 that if only \ escapes are used, the local shell will utilize those escapes and rsync will never see them. For every level of shell an escape \ does its job. If you want rsync to interpret a space char as other than whitespace then a \ is one way to do so. But one we are talking about the other side of an rsync we are talking about a local command line that consumes a \. Then we are talking about a remote command line that consumes another \. So, within the -e parameter, multiple stacked \ characters are required. Simply put, it is absolutely absurd to \ escape an rsync command line while interpreting the subshell -e parameter and the remote shell parameters the same way. At best you are insisting that ssh do something entirely nonsensical while ensuring that the first s in "ssh" is interpreted as an "s". On 10/28/2016 10:10 PM, Wayne Davison wrote:> > On Fri, Oct 28, 2016 at 5:39 AM, Samuel Williams > <space.ship.traveller at gmail.com <mailto:space.ship.traveller at 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, 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 to rsync, not trying to guess what rsync is going to do with it > after it gets it. > > To work around that bug, you could consider using an ssh-calling shell > script instead of manually specifying the ssh command and args to rsync. > > ..wayne.. > >-- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., Kevin Korb Phone: (407) 252-6853 Systems Administrator Internet: FutureQuest, Inc. Kevin at FutureQuest.net (work) Orlando, Florida kmk at sanitarium.net (personal) Web page: http://www.sanitarium.net/ PGP public key available on web site. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/rsync/attachments/20161028/faff998c/signature.sig>
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 sure in what reality this makes any sense. All I'm proposing is that the do_cmd split function interprets the -e as a string that would normally be executed on the command line, and if it needs to be split, follow the normal rules of the command line for handling whitespace. On 29 October 2016 at 16:24, Samuel Williams <space.ship.traveller at gmail.com> wrote:> 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 sure in what reality this makes any sense. All I'm > proposing is that the do_cmd split function interprets the -e as a > string that would normally be executed on the command line, and if it > needs to be split, follow the normal rules of the command line for > handling whitespace. > > On 29 October 2016 at 15:41, Kevin Korb <kmk at sanitarium.net> wrote: >> 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 that if only \ escapes are used, the local shell will >> utilize those escapes and rsync will never see them. >> >> For every level of shell an escape \ does its job. >> >> If you want rsync to interpret a space char as other than whitespace >> then a \ is one way to do so. >> >> But one we are talking about the other side of an rsync we are talking >> about a local command line that consumes a \. Then we are talking about >> a remote command line that consumes another \. So, within the -e >> parameter, multiple stacked \ characters are required. >> >> Simply put, it is absolutely absurd to \ escape an rsync command line >> while interpreting the subshell -e parameter and the remote shell >> parameters the same way. >> >> At best you are insisting that ssh do something entirely nonsensical >> while ensuring that the first s in "ssh" is interpreted as an "s". >> >> >> On 10/28/2016 10:10 PM, Wayne Davison wrote: >>> >>> On Fri, Oct 28, 2016 at 5:39 AM, Samuel Williams >>> <space.ship.traveller at gmail.com <mailto:space.ship.traveller at 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, 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 to rsync, not trying to guess what rsync is going to do with it >>> after it gets it. >>> >>> To work around that bug, you could consider using an ssh-calling shell >>> script instead of manually specifying the ssh command and args to rsync. >>> >>> ..wayne.. >>> >>> >> >> -- >> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., >> Kevin Korb Phone: (407) 252-6853 >> Systems Administrator Internet: >> FutureQuest, Inc. Kevin at FutureQuest.net (work) >> Orlando, Florida kmk at sanitarium.net (personal) >> Web page: http://www.sanitarium.net/ >> PGP public key available on web site. >> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., >> >> >> -- >> Please use reply-all for most replies to avoid omitting the mailing list. >> To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync >> Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
> 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 to rsync, not trying to guess what rsync is going to do with it after it gets it.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\ \a\ \s\t\r\i\n\g I'm a string