Date: Thu, 28 Mar 2002 23:17:02 +0200 (EET) From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: "Patrick O'Reilly" <bsd@perimeter.co.za> Cc: "Scott M. Nolde" <scott@smnolde.com>, <freebsd-questions@freebsd.org> Subject: Re: find | cpio syntax Message-ID: <20020328224416.U1966-100000@hades> In-Reply-To: <00ed01c1d637$4c5ccca0$b50d030a@PATRICK>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-03-28 11:02, Patrick O'Reilly wrote:
> I did this and it worked fine:
> # cd /local/path/to/be/tarred
> # tar czf /tmp/1.tgz .
> # scp /tmp/1.tgz myuserid@hostname.com:/full/path/to/remote/tarball.tgz
That works, yes :-)
> I did try:
> # tar czf - . ; scp -
> myuserid@hostname.com:/full/path/to/remote/tarball.tgz
> but that did horrible things to my terminal, so don't do it :)
It's what onne should expect. You passed - as the output file argument to
tar(1) which will make tar(1) write it's output to the terminal. The
archives created by tar(1) though do not contain only printable ASCII
characters, and displaying a raw, binary file on a terminal, is bound to
mess the terminal in weird, unexpected ways. See below for an example that
uses a pipe to pass data from one host to the other, using ssh(1) as a
tunnel.
> You can also do scp between two remote hosts, I believe, but I have
> never tried it.
scp(1) can copy existing files from a local host to a remote one, or from a
remote host to a local one. The file has to exist before scp(1) can get
it's hands on it though. Any sequence of commands that generates an
intermediate file will work with scp(1), just like cp(1) needs the source
file to exist before being able to copy it.
You need to use pipes, and ssh(1) as a tunnel over which the data will
pass, if you don't want to create temporary, intermediate files though. To
understand why this works, you might want to try commands like:
ssh -l username host 'cat ~/FILE'
>>> Note the use of single quotes to inhibit expansion of the tidle
>>> character (`~') by the local shell.
Then, try this:
ssh -l username host 'cat ~/FILE' | more
The pipe is expanded by the local shell, and the output of the cat(1)
command that ssh(1) executes on the remote host, passes through the ssh(1)
connection back to the local host, where it's piped into more(1).
The other way round, you can redirect the output of a local command, to be
sent to the input of a remote command, using ssh(1):
cat FILE | ssh -l username host 'nl'
Here, cat(1) prints the FILE in the standard input of ssh(1) which sends
its input to the standard input of the nl(1) command, running on the remote
host. Then nl(1) numbers the output lines, and prints data to its standard
output, which ssh(1) passes back to the local host. This is bound to be
damn slow, since running nl(1) locally is certainly a lot faster, but it
serves as a nice example of standard input/output redirection over ssh
links.
A more complicated example, which runs multiple local commands, and multile
remote commands, using ssh(1) to connect the standard output of a local
pipeline to the standard input of a remote pipeline, is shown below:
tar cvf - foo/ | gzip -9c - | ssh -l username host 'gzip -cd | tar xf -'
This makes a tarball of local directory foo/, which is written to the
standard output of tar(1). Then the first gzip(1) compresses the data (to
save a few bandwidth bytes, since this will travel over the wire). The
ssh(1) command reads gzip(1)'s output, and sends it to the standard input
of a shell command running on the remote host.
The remote command runs gzip(1) first to uncompress the gzipped file that
ssh(1) feeds it, and then passes the unzipped data to tar(1)'s standard
output for extraction. Voila! A simple shell command to copy a directory
structure over an ssh(1) link :-)))
The reverse, which copies data FROM the remote host TO the local machine,
is easy to guess after this:
ssh -l user host 'tar cvf - . | gzip -9c -' | gzip -cd | tar xf -
There are of course equivalent things that one can craft, using scp(1) and
temporary files, but this is so nice that I rarely use scp(1).
But enough with all this,
I've gone too far again.
Giorgos Keramidas FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr} http://www.FreeBSD.org/docproj/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020328224416.U1966-100000>