From: Michael Sullivan Date: 2002-01-22T12:15:08+09:00 Subject: Re: [OT] Re: zip on Linux (or any other *nix) Alright, I just had to respond to this and correct a misconception or two and before someone mentions Nazis... :) I've been using gzip from way back and more recently bzip2. Before that there was "compress" and "pack". compress was tighter than pack and pack was a throwback to the 70's mainframes, perhaps earlier. pack also has a friend called pcat as well as unpack. Generally: .z a file compressed with "pack" .Z a file compressed with "compress" .gz a file compressed with "gzip" .bz2 a file compressed with "bzip2" Check out the man pages. On Tue, Jan 22, 2002 at 11:31:13AM +0900, Eric Lee Green wrote: > In article , Mathieu > Bouchard wrote: > > On Mon, 21 Jan 2002, Eric Lee Green wrote: > >> Mathieu Bouchard wrote: > >> > The problem with .zip is that it was Not Invented Here (NIH). > >> Err, no. The problem with .zip is that it was invented over five years > >> after .tar.Z became standard on Unix. > > > > Well that maybe one problem. But there's still a significant advantage at > > using .zip, or any other similar format. > > What advantages? People talk about the ability to retrieve a random file > from a zip archive. Guess what -- I have *NEVER* done that. It's always > been a case of when I unzip an archive, I unzip it, I don't pull just one > file from it. Using most tar commands, you can select out individual files. Some are easier than others. The "-w" switch on Solaris tar asks the user what action should be taken when it encounters the file. I've never extracted a single file from a tar bundle, never really wanted to, but it can be done. [Richard Stallman drivel..] [Much ado about "PkZip"...] > gzip is a very slow compression program, BTW. It is slower than hoary > old "compress", though it compresses better. One of my co-workers > benchmarked pretty much every compression program and subroutine out > there, and found that the fastest was one called 'lzop' (though it did > not compress as well as gzip). The patent situation with that one, > however, is unknown. > > > A lot of compression algorithms are regularly invented that beat gzip and > > even beat bzip2; the latter only got more attention because it was > > implemented with a gzip-like interface. > > Hmm, care to mention one that compresses tighter than bzip2? When that > co-worker benchmarked compression routines he could not find one, but he > did note that bzip2 was extremely slow. > > >> and many Unix programs are now packaged as both .tar.gz and .tar.bz2 > >> files, just as, during the transition from .Z to .gz in the early > >> 90's, many Unix programs were packaged as both .Z and .gz files. > > > > I don't see bz2 replacing gzip, because bz2 compression is not streamable. Totally incorrect! bzip2 is streamable. Do it all the time myself. For instance, amaze your friends: tar cvf - . | bzip - > /tmp/somefile.tar.bz2 Works like: tar cvf - . | gzip - > /tmp/somefile.tar.gz To uncompress... bzcat /tmp/somefile.tar.bz2 | tar xvf - Little known fact, one can make a link: ln gzip gzcat Then one can use gzip like zcat. gzcat /tmp/somefile.tar.gz | tar xvf - > ? Most people use gzip or bzip2 in the context of compressing tarballs. > Granted, bzip2 is not going to replace gzip for anything requiring speed, > but nobody really cares. It's like with pkzip. Sure, you can access random > files in a pkzip archive. But who cares? Every .zip file I've ever downloaded > for Windows, I did one thing to it -- I unzipped the whole thing and > clicked on the "setup.exe" file. A very good point. That's what I've done with most of them. Facts: 1. Compressing takes a lot of time no matter what compression you use. 2. Uncompressing is much faster than compressing using any utility you care to. 3. The tighter the compression the more time it takes to compress, again no matter what utility you use. 4. Since most people uncompress archives on the Internet as opposed to compressing them - usually done when a distribution is built, and lots of people want archives to download as fast as possible so... it makes sense to use the tightest compression possible for saving bandwidth and disk space (and I know disk is cheap). 5. "unzip" is available as source and builds nicely on most *nixes. (though I'm no particular fan, but Sun even distributes some patches this way) 6. Compression is one of the many operations which slows down data encryption. Generally data is compressed then encrypted so it is less vulnerable to cracking. AFAIK, most Winows unzipware is able to read gzipped tar files. If yours doesn't then perhaps upgrade. Or, an alternative is to use CYGWIN. I happen to have found my VMWare Windows 2000 instance useful for "self extracting archives" which are .exe files, in addition to running Quicken. Happy packing, compressing, gzipping, bzipping, pkzipping and zipping around in general... :) Now let's get back to Ruby. Mike -- Michael P. Sullivan Distributed Computing Systems, LLC Cell: 516-429-2080 E-Mail: mps@discomsys.com http://www.discomsys.com/ * UNIX Systems and Database Consulting, Architecture and Management * "Failing to plan, is planning to fail... plan for the worst, hope for the best"