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

Brian K. White brian at aljex.com
Wed Oct 19 23:36:59 MDT 2011

On 10/19/2011 11:38 PM, Cameron Simpson wrote:
> 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.

Your use case description in no way implies using the same protocol and 
the same client app on each hop. Every single hop from one box to 
another, implies a new chance for that hop to work differently from 
others. Just because ssh is common really means nothing.

You are arguing the option should be more generic than it is, for the 
good of all, not to unnecessarily break unpredicted use cases.

Yet are ok with it only working for what you happen to need, assuming 
standard ssh all the way, because that's all you need.

You have to pick one or the other philosophy or else no one has to care 
what you want because it just means you want what you want like everyone 
else. I want lots of stuff but I don't ask for it unless it might be 
generally useful for anyone.

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

For several years I used rsync regularly between SCO Open Server boxes 
that had no ssh, and could not have it either, but did have rcmd. (on 
SCO "rsh" is a plain old local /bin/sh with restricted features for 
reduced privilege sessions. What linux calls rsh, sco calls rcmd.) I 
either used -e rcmd --rsync-path=/usr/local/bin/rsync, or compiled my 
own rsync with those options set as default.

Most of those boxes have died by now, but so what?
Also, it's only most, not all.

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

More importantly, some telnet clients and some telnet servers can be 
made 8-bit clean, but generally require options or run-time command-mode 
commands that rsync can't do. But if rsync were more generic in this way 
it could. Then again I could always write a wrapper script that would 
work. There is also telnet-ssl.

With kermit I can make an 8 bit clean and error correcting serial 
connection too, though I've never actually tried to run rsync over it, 
but I'm pretty curious about it now that I say it. Heck I wonder if 
rsync even needs the error-correcting part.

The occasion hasn't occurred yet where I had serial console access to a 
remote box, could not restore normal network access, and needed to 
transfer more files than plain whole-file zmodem over 115k was fine for. 
But I'd love to have such a thing as rsync over serial without ppp in my 
toolbox of magic exotic guru tricks.

But my point was as stated above, just that assuming a single protocol 
for all hops is no nicer than assuming a single hop. Whether there are 5 
or more possible connection types or just 2 is unimportant. Any day 
someone may make up a new one.

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


More information about the rsync mailing list