why does rsync translate user at host into '$RSYNC_RSH -l user host'?

Cameron Simpson cs at zip.com.au
Wed Oct 19 21:38:25 MDT 2011


On 19Oct2011 22:14, Brian K. White <brian at aljex.com> wrote:
| On 10/19/2011 6:58 PM, Cameron Simpson wrote:
| >On 19Oct2011 12:02, Benjamin R. Haskell<rsync at benizi.com>  wrote:
| >| rsync has to parse the URL you're passing.  The fact that it then
| >| takes that and runs something like `$RSYNC_RSH -l user host` is
| >| because rsync expects it's handing the connection duties off to
| >| something that uses rsh-like calling conventions.  So, it's
| >| "desirable" because rsh-like tools traditionally expect it.
| >
| >But rsh-like tools _all_ accept user at host already.
| >They don't "expect" the "-l" form - they cope with it.
| >
| >This argument does not make it desirable unless rsh or ssh don't cope
| >with user at host. Which they do.
| >
| >| If rsync didn't parse the URL and split it out, each tool would have
| >| to do its own {user}@{host} parsing.  So, it's not fully
| >| "necessary". (Most of the tools probably do have that kind of
| >| parsing.)  It just makes things easier for tools that use the '-l'
| >| convention.
| >
| >The point here is the rsync is presuming to know about the tool. The
| >whole point of the -e and $RSYNC_RSH stuff is to use arbitrary tools.
| >Having rsync pull out the user doesn't _help_ rsh or ssh, both of which
| >has always (AFAIR) accepted user at host and does raise the implementation
| >bar for other tools for no actual benefit.
| >
| >Has anyone a use case that _breaks_ if rsync doesn't pull out what it
| >imagines is the "user@" part?
| 
| I think it's not reasonable to expect complex muti hops like that to
| work. For instance, they only work for you because you just luckily
| happen to be using all the same kind of tool for all hops.

Within the same administrative domain it is entirely reasonable.
The very name of the script "sshto" says I probably expect ssh all the way.

Out of curiosity, how many non-ssh rsync setups have _you_ encountered
in the wild? (Ignoring "rsync daemon" stuff.)

| It's not a common case. Would your trick work if any of the hops had
| to be rsh or telnet or serial? If any of the hops used a nonstandard
| tcp port?

Do people use rsync over telnet? I concede that telnet accepts -l and
doesn't accept user at host. But is this a real world example?

A nonstandard port is indeed not addressed unless there's a handy
ssh_config clause.

| I do agree I'd rather rsync didn't try to parse anything it didn't
| have to. Maybe I don't think this situation is general enough to go
| out of the way to support, but I do agree it's undesirable to go out
| of the way to break it without some specific reason, and a reason
| that's overall worth more.

Well, I've modified my script to unmangle rsync's overparsing, so my
particular problem is resolved. But I think reading extra structure into
the [user@]host: part is a misfeature at best.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

What if you are underpaid?  Know the joy of being worth more than you get -
the pure joy of unrecognized superiority.       - Rev. S. M. Smith


More information about the rsync mailing list