rget, rput - network pipe

     rput keyword [command [arg ...]]
     rget -h remote-host keyword [command [arg ...]]

     Rput and rget set up a TCP/IP channel to connect two processes  together.
     They can looked upon as a remote pipe.  Consider the well known method of
     copying a directory tree with tar:

          (cd src && tar cf - .) | (cd dst && tar xfp -)

     If the directory tree is to be copied to another machine then one can use
     the following command on the source machine:

          cd src && rput foo tar cf - .

     And on the destination machine:

          cd dst && rget -h source-machine foo tar xfp -

     The keyword is used to cook up a TCP port number for the  connection,  it
     must be the same for both commands to allow rget to find the remote rput.
     It is customary to start rput first,  although  rget  will  retry  for  2
     minutes trying to connect to the remote rput.

     After the connection is established either utility will  execute  command
     with  the  given arguments with the TCP channel as either standard output
     (rput) or standard input (rget).  Rput and rget do not  stay  around  for
     the  command  to finish, they simply overlay themselves with the command.
     If no command is given then they will themselves copy standard input into
     the TCP channel (rput), or output from the TCP channel to standard output
     (rget).  So these two commands have the same effect:

          rput foo tar cf - .
          tar cf - . | rput foo

     The second form has two  processes  copying  data  instead  of  just  tar
     directly  writing its output into the TCP channel.  There is a better way
     to waste processor cycles, namely to save bandwidth:

          cd src && tar cf - . | rput foo compress

          cd dst && rget -h source-machine foo uncompress | tar xfp -

     Rput and rget can be very useful in  the  windowed  environments  we  use
     these  days.   The  rput  can  be  typed into the window that has a shell
     running on one machine, and the rget is then typed into the  window  that
     has  a  shell running on another machine.  This is easier than one of the
     two well known forms that use rsh:

          cd src && tar cf - . | rsh dest-machine "cd dst && tar xfp -"

          cd dst && rsh source-machine "cd src && tar cf - ." | tar xfp -

     Especially since these forms require that one must be  able  to  use  rsh
     without a password, which may not always be the case.

     The keyword  can  be  any  string  of  characters  of  any  length.   The
     characters  binary  values are multiplied together, bit 15 is set and the
     result is truncated to 16 bits to make it a port number in the  anonymous
     port  space  (32768  -  65535).   The  port  may  be in-use on the source
     machine, but there is a small chance of this happening, and if so  simply
     choose  another  keyword.   (This  does  mean that rput and rget are only
     useful interactively, because a connection can't be guaranteed.)


     -h remote-host
          The name of the remote host that rget must contact to find the rput.
          This  option  is  currently  mandatory.   The  author is planning on
          letting rget find rput with UDP broadcasts or multicasts.  (This  to
          make  the rget call symmetric with rput, of course, not just to save
          a few keystrokes.)



     rput: Address in use
          If the port computed out of keyword is already in use.

     Kees J. Bot (kjb@cs.vu.nl)