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/[EMAIL PROTECTED]> strace -e trace=process -f /opt/bin/rsync -avHP
/mnt/phat/archives/silva/. [EMAIL PROTECTED]:/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 "[EMAIL PROTECTED]" 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 [EMAIL PROTECTED] 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
"[EMAIL PROTECTED]:" 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 <[EMAIL PROTECTED]> 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
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
