On 10/19/2011 11:38 PM, Cameron Simpson wrote:
On 19Oct2011 22:14, Brian K. White<br...@aljex.com> wrote: | On 10/19/2011 6:58 PM, Cameron Simpson wrote: |>On 19Oct2011 12:02, Benjamin R. Haskell<rs...@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@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@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@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.
http://www.aljex.com/bkw/sco/#rsync 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@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,
-- bkw -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
