rsync over stdin/stdout

[Tony Mantler]

On Mon, 2008-06-02 at 14:49 -0700, Matt McCutchen wrote:
> On Mon, 2008-06-02 at 14:29 -0700, Tony Mantler wrote:
> > On Mon, 2008-06-02 at 13:45 -0700, Matt McCutchen wrote:
> > > On Mon, 2008-06-02 at 11:27 -0700, Tony Mantler wrote: 
> > > > Basically I need to set up the socket beforehand and then hand it to
> > > > rsync somehow. This seems to be possible on the 'remote' end, but I
> > > > haven't managed to figure out how to do on the initiation side.
> > > 
> > > First, you should use an rsync daemon if you aren't already; with the
> > > remote shell mode, you have to get the server arguments across the
> > > socket yourself, whereas the daemon protocol takes care of that.
> > 
> > The program I have handles that fairly well, actually. It's not too far
> > removed from complete rsh functionality.
> 
> I don't understand.  If your connection program is like rsh, it passes
> arguments and then gives you a socket to talk to the invoked program.
> But the server arguments are not determined until you start the rsync
> client, after the socket has been set up.  So how could the server
> arguments be passed by the connection program?  Or do you just mean that
> the connection program passes "rsync --server --daemon ." without you
> having to hardcode that on the remote side, in which case we're really
> talking about the same thing?

Well, when operating in the 'rsh'-like mode, rsync passes a bunch of
arguments to my program which my program hands across to the other side
to invoke the remote-side rsh.

What I need to do is turn this whole thing inside out, so that my
program launches rsync rather than rsync launching my program. The
reason for this is that my program needs to operate as a plugin as well
as standalone.


> > > In the absence of this enhancement, you can accomplish the same thing
> > > using the RSYNC_CONNECT_PROG environment variable [...]
> 
> > > RSYNC_CONNECT_PROG='cat >&3 & cat <&3; wait' rsync -a foo::module/src/ dest/
> 
> > That probably won't work very well in my case.
> 
> Why not?  It does exactly the same thing as the enhancement would, but
> with slightly higher overhead to pass the data back and forth.

Well, it won't work on windows for one thing, and that's apparently one
of my target platforms. (not by choice, I assure you)