[Mike Fieschko]

When you get these tarballs, you uncompress them (if they were compressed) and then feed them into the tar program to unpack all the files out onto the disk, with a command like:

"$ tar xvf tarball.tar"

and you’ll see the ‘tar’ program extract all the files.

If the tarball were compressed (eg, with a .gz suffix), you’re uncompress the tarball and then feed it into tar:

"$ zcat tarball.tar.gz | tar xvf -"

and so on. The “zcat” command uncompressed the .gz file and writes the result to the “standard output.” If you didn’t re-direct the output into the tar program with the pipe “|” command, you’d get a huge screenful of stuff and then you’d be left with the original .gz file and no net results.

Do you think zcat and pipe are needed? They're not needed and unnecessarily complicated. tar itself handles .gz files, avoiding zcat and piping.

Using tar's z option will first uncompress (actually, gunzip, since compress creates .Z files, not .gz files) the gzipped tarball. This is true for gnu tar, FreeBSD tar, Mac OS X tar, Solaris tar, and probably others.

tar's z option avoids the need to zcat and pipe, or avoids the need to run gzip -d on the file.

Similarly, if the tarball was bzipped, tar's j option will bunzip the tarball.

So, in the case of a .tar.gz, a simple

$ tar zxvf tarball.tar.gz

does the trick.

And, if you have a bzipped tarball

$ tar jxvf tarball.tar.bz2

does the trick.

[NVDave]

On Linux, you’re absolutely right.

I’m an old-school Unix guy, and when I’m tossing off examples like this, I’ll use what I know are methods that will work on most any flavor of Unix, going back years and years...

In a couple of years, I’ll be suitably aged to wave my cane at kids and yell at them to “get off my network!”