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

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@jazzbo*> strace -e trace=process -f /opt/bin/rsync
-avHP /mnt/phat/archives/silva/. root@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@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@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@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

On Wed, Jun 08, 2005 at 02:14:05PM +1000, Cameron Simpson
wrote:
> in short, rsync is seeing the "root@ali" and invoking:
> 
> 	ssh ali -l root rsync-daemon-invocation...
This should only happen if remsh is present on your system when
configure was run.  This is because remsh requires that arg order (and
ssh accepts either arg order).  The code in 2.6.4 accidentally made all
remote-shell invokations use the remsh arg order, but 2.6.5 fixed that
bug.  Did you upgrade from 2.6.4 without re-running configure?  (If you
used the config.h file from a 2.6.4 build, you'd not see the fix.)  Or
does your system now have a remsh binary installed in the path?

..wayne..