Decompressing Tarballs


"Yeah, Yeah, I know how to do that".

Or do you?

This may seem trivial to some of you, but here's some good practice I
recommend you get into:

When you're on any non-GNU-based system, tar probably doesn't have the
ability to decompress anything.

And between even otherwise-similar GNU systems, tar sometimes takes
different options for even the same thing, notably making your bzip2
automated-installed not work between different linux boxen. One day,
this will bite you, and you will wish you'd listened to me.

To decompress tarballs of varying flavors:

bzcat file.tar.bz2 | tar -xf -
gzcat file.tar.gz  | tar -xf -
zcat  file.tar.z   | tar -xf -

Can anyone see some similarities, that actually make this easier to
remember than varying obtuse options to tar?

The explanation, by the way, is simple: You decompress a file to standard
output, then ask tar to decompress the tar file on standard input. That's
what the filename "-" means.

Sometimes, you don't have "gzcat" or "bzcat" avaialble. That's fine. In
that case, replace the relevant command with "command -cd", eg:

gzip  -cd file.tar.gz  | tar -xf -
bzip2 -cd file.tar.bz2 | tar -xf -

Slightly harder to remember, but I urge you to get into the habit of
using the "-cd" varaints, actually, as they work more generally.

And if you decompress something, then untar it, /a la/

bunzip2 file.tar.bz2
tar -xf file.tar

That's fine too, except that you lost the original file - hence, you
can't verify md5sums, or archive the file off for future reference
[without changing the MD5, hence allowing someone to trojan your box]


And the inverse

In order to /create/ a tarball, you simply have to do the inverse of
the above:

tar -cf - directory | gzip  -c > directory.tar.gz
tar -cf - directory | bzip2 -c > directory.tar.bz2

You do not need to create ".z" files, but if you really feel the urge,
it's a better bet to tarball, then compress;
tar -cf directory.tar && compress directory.tar


Tricks that are in some way related to this

Pushing files through firewalls when you really shouldn't be:
tar -cf - file | rsh hostname "cd target_dir;tar -xf -"

Works, notably, when you're running a kerberised box and only rsh is
allowed through the firewall [yes, I've used this extensively and in
earnest before in order to actually get my job done]

If you find that your computers are faster than the connection between
then, you can compress the data on it's way:
tar -cf - file | gzip -c | rsh hostname "cd target_dir;gzip -cd | tar -xf -"

Or if your computers are much faster than the connection between them:
tar -cf - file | bzip2 -c | rsh hostname "cd target_dir;bzip2 -cd | tar -xf -"

I still use that one on 56k.

It should also be noted something interesting here: You do not need,
at any point, secondary storage for the tarball. What this means is
that if you're putting files onto a box that doesn't have enough space
to hold two copies of all the files, this can be used.

In my experience, I used this to put a copy of quake3 on my firewall a
couple years ago for serving purposes. The firewall didn't have the 4G
spare it was necessary to have in order to copy the tarball over there,
then decompress it; so this uses up no more than the final footprint
will be.


And a final note;
Backups

cd /home
tar -cf - chunky | bzip2 -c > /backups/chunky-`date -I`.tar.bz2

Do not put a "/" on the end of the first "chunky", as tar will give out
unhelpful and confusing error messages, that you are thoroughly forgiven
for getting confused by [Hiya, Dana]

Do not make the backup in the directory you're backing up (=


Just my .02 that you're free to ignore. Most of the above will never make
a difference to you, it's just that if it ever does, you'll know about it.

Gary (-;