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

[Brian K. White]

On 10/19/2011 6:58 PM, Cameron Simpson wrote:
> On 19Oct2011 12:02, Benjamin R. Haskell<rsync at benizi.com>  wrote:
> | On Wed, 19 Oct 2011, Kevin Korb wrote:
> |>Because it is an even bigger joy to be able to type 'ssh newhost'
> |>and have it just work even though you can't talk to newhost.  You
> |>can do that by properly configuring ssh in ~/.ssh/config with
> |>something like this:
> |>
> |>Host accessiblehost
> |>  User cameron
> |>
> |>Host newhost
> |>  ProxyCommand ssh accessiblehost -W %h:%p
> |>  User root
> |
> | +1.  Seems easier than a DIY script.
>
> You guys are kidding, surely? You hand edit your ssh configs for every
> ah doc chain of hosts you might want? So when I go:
>
>    for h in a b c d e; do sshto transithost!$h do_foo; done
>
> you find it easier to make a bunch of ssh config clauses first, each
> with cool distinctive names? I salute your typing skills.
>
> (Besides, I wrote my first sshto tool before the ProxyCommand directive
> existed.)
>
> | But to answer the original question:
> |
> |>On 10/19/11 03:40, Cameron Simpson wrote:
> |>>Why does rsync believe it knows more about the use of the token
> |>>to the left of the colon than the program which will be used as
> |>>the remote connection?
> |>>
> |>>[...]
> |>>
> |>>what it invokes is:
> |>>
> |>>   sshto -l cameron at accessiblehost!root newhost rsync .....
> |>>
> |>>Since sshto is my own tool I can probably have it cope with this
> |>>mangling of my target string into "-l foo bah", and undo it.
> |>>
> |>>But WHY does rsync believe this is desirable, or even necessary?
> |
> | 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?
>
> Cheers,

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.

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?

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.

-- 
bkw