170 lines
4.4 KiB
Groff
170 lines
4.4 KiB
Groff
|
.TH RGET 1
|
||
|
.SH NAME
|
||
|
rget, rput \- network pipe
|
||
|
.SH SYNOPSIS
|
||
|
.B rget
|
||
|
.RB [ \-lcio ]
|
||
|
.RB [ \-h
|
||
|
.IR host ]
|
||
|
.I key
|
||
|
.RI [ command
|
||
|
.RI [ arg " ...]]"
|
||
|
.br
|
||
|
.B rput
|
||
|
.RB [ \-lcio ]
|
||
|
.RB [ \-h
|
||
|
.IR host ]
|
||
|
.I key
|
||
|
.RI [ command
|
||
|
.RI [ arg " ...]]"
|
||
|
.SH DESCRIPTION
|
||
|
.de SP
|
||
|
.if t .sp 0.4
|
||
|
.if n .sp
|
||
|
..
|
||
|
.de XS \" Example start
|
||
|
.SP
|
||
|
.in +4m
|
||
|
.nf
|
||
|
..
|
||
|
.de XE \" Example end
|
||
|
.fi
|
||
|
.in -4m
|
||
|
.SP
|
||
|
..
|
||
|
.B Rput
|
||
|
and
|
||
|
.B 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
|
||
|
.BR tar :
|
||
|
.XS
|
||
|
(cd src && tar cf \- .) | (cd dst && tar xfp \-)
|
||
|
.XE
|
||
|
If the directory tree is to be copied to another machine then one can
|
||
|
use the following command on the source machine:
|
||
|
.XS
|
||
|
cd src && rput foo tar cf \- .
|
||
|
.XE
|
||
|
And on the destination machine:
|
||
|
.XS
|
||
|
cd dst && rget \-h \fIsource-machine\fP foo tar xfp \-
|
||
|
.XE
|
||
|
The
|
||
|
.I key
|
||
|
is either a port number in C style decimal, octal or hex, or a random string
|
||
|
that is hashed to a port number.
|
||
|
.B Rput
|
||
|
uses this port number to open a TCP socket that
|
||
|
.B rget
|
||
|
using the same
|
||
|
.I key
|
||
|
can connect to.
|
||
|
It is customary to start
|
||
|
.B rput
|
||
|
first, although
|
||
|
.B rget
|
||
|
will retry for 2 minutes trying to connect to the remote
|
||
|
.BR rput.
|
||
|
.PP
|
||
|
After the connection is established either utility will execute
|
||
|
.I command
|
||
|
with the given arguments with the TCP channel as either standard output
|
||
|
(rput) or standard input (rget).
|
||
|
.B Rput
|
||
|
and
|
||
|
.B 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:
|
||
|
.XS
|
||
|
rput foo tar cf \- .
|
||
|
tar cf \- . | rput foo
|
||
|
.XE
|
||
|
The second form has two processes copying data instead of just
|
||
|
.B tar
|
||
|
directly writing its output into the TCP channel. There is a better way to
|
||
|
waste processor cycles, namely to save bandwidth:
|
||
|
.XS
|
||
|
cd src && tar cf \- . | rput foo compress
|
||
|
.SP
|
||
|
cd dst && rget \-h \fIsource-machine\fP foo uncompress | tar xfp \-
|
||
|
.XE
|
||
|
.B Rput
|
||
|
and
|
||
|
.B rget
|
||
|
can be very useful in the windowed environments we use these days. The
|
||
|
.B rput
|
||
|
can be typed into the window that has a shell running on one machine, and
|
||
|
the
|
||
|
.B 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
|
||
|
.BR rsh :
|
||
|
.XS
|
||
|
cd src && tar cf \- . | rsh dest-machine "cd dst && tar xfp \-"
|
||
|
.SP
|
||
|
cd dst && rsh source-machine "cd src && tar cf \- ." | tar xfp \-
|
||
|
.XE
|
||
|
Especially since these forms require that one must be able to use
|
||
|
.B rsh
|
||
|
without a password, which may not always be the case.
|
||
|
.PP
|
||
|
The
|
||
|
.I key
|
||
|
can be any string of characters of any length. If its a number then it is
|
||
|
used directly as the port number. Otherwise 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 key. (So if you use
|
||
|
.B rput
|
||
|
and
|
||
|
.B rget
|
||
|
in an unattended script then you should reserve a port number, otherwise
|
||
|
a connection can't be guaranteed.)
|
||
|
.SH OPTIONS
|
||
|
.TP
|
||
|
.B \-lcio
|
||
|
These flags allow one to reverse the default connect/listen or input/output
|
||
|
direction of
|
||
|
.BR rput
|
||
|
and
|
||
|
.BR rget .
|
||
|
Reversing the connection may be necessary if one of the two systems filters
|
||
|
out connections to unknown ports. For example:
|
||
|
.XS
|
||
|
rput \-c \-h \fIdestination-machine\fP foo tar cf \- .
|
||
|
.SP
|
||
|
rget \-l foo tar xfp \-
|
||
|
.XE
|
||
|
The
|
||
|
.B \-io
|
||
|
options can be used to choose which of standard input or output should be
|
||
|
tied to the socket. It's even possible to tie both input and output to the
|
||
|
socket with
|
||
|
.BR \-io,
|
||
|
but only when executing a command. This is probably the only use for these
|
||
|
options, because one usually chooses the direction with the mnemonic put/get
|
||
|
names.
|
||
|
.TP
|
||
|
.BI \-h " host"
|
||
|
The name of the remote host that a connection must be made to. It must be
|
||
|
used with the program that is doing the connect, usually
|
||
|
.BR rget .
|
||
|
This option is currently mandatory. The author is planning to increase
|
||
|
ease of use by letting the programs find each other with UDP broadcasts
|
||
|
or multicasts.
|
||
|
.SH "SEE ALSO"
|
||
|
.BR rsh (1).
|
||
|
.SH DIAGNOSTICS
|
||
|
.TP 5
|
||
|
rput: Address in use
|
||
|
If the port computed out of
|
||
|
.I key
|
||
|
is already in use.
|
||
|
.SH AUTHOR
|
||
|
Kees J. Bot <kjb@cs.vu.nl>
|