BUG REPORT: latest rsync misinvokes ssh with user@host ...

[Cameron Simpson]

The latest rsync (2.6.5) seems to invoke the transport specified by
$RSYNC_RSH differently. I have this set to point at an ssh wrapper script
(which is now I noticed), and an strace shows this:

  [archives/silva]#root at jazzbo*> strace -e trace=process -f /opt/bin/rsync -avHP /mnt/phat/archives/silva/. root at ali:/a/ali/home/.............
  [...snip...]
  execve("/u/cameron/scripts/rsync_rsh", ["rsync_rsh", "ali", "-l", "root", "rsync", "--server", "-vlHogDtpr", "--partial", ".", "/a/ali/home/........."...], [/* 201 vars */]) = 0

in short, rsync is seeing the "root at ali" and invoking:

	ssh ali -l root rsync-daemon-invocation...

This is Very Wrong. It should be:

	ssh -l root ali rsync-daemon-invocation...

or better still just:

	ssh root at ali rsync-daemon-invocation...

i.e. not have rsync try to be smart about the host: prefix to the target.

I've hacked my wrapper to cope with this misinvocation, but even a
transient glance at the ssh manual entry SYNOPSIS section should show
this is wrong, and of course in violation of all the usual UNIX command
line conventions where the options preceed the arguments.

I can only assume some loose parsing in the ssh command itself has
permitted this to go unnoticed.

Personally I'm of the opinion that rsync shouldn't parse the
"[user@]host:" prefix at all (other than detecting it), and should not
break it into "-l user" and "host".

Can someone elucidate the reasoning behind this change?

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

If you pick up a starving dog and make him prosperous, he will not bite you.
This is the principal difference between a dog and a man.       - Mark Twain