[Linux-disciples] bzip2 and directories

Adam Rosi-Kessel adam at rosi-kessel.org
Wed Jul 7 11:05:27 EDT 2004


On Wed, Jul 07, 2004 at 10:50:03AM -0400, Stephen R Laniel wrote:
> On Wed, Jul 07, 2004 at 10:29:40AM -0400, Adam Rosi-Kessel wrote:
> > That whole "zip a directory" thing is very Win32ish.
> I don't know about that. It's only a silly idea to zip a
> directory and its contents if you view the job of a
> compressor as 'zip one file.' If you admit the possibility
> that a compressor should be able to compress more than one
> file at a time, then it seems reasonable to at least make
> something like
> gzip `find .`
> admissible. You're still separating the task of 'compress
> files' from the task of 'get the list of files to compress.'

Very different function.  gzip `find .` gzips every file it finds under
the current directory, separately.  bzip2 `find .` works the saem.

> Besides: if tar's already integrated enough with gzip and
> bzip2 that you can call the compressors from inside tar,
> then it seems they've already recognized the usefulness of
> integrating the two functions.

It's not that it's not useful to combine the two functions, but that it's
preferable to keep them as separate packages that are 'black boxes' to
each other.  If you had a superior bzip2 or gzip that was otherwise
wholly compatible with the standard version, you could just drop them in
place and tar wouldn't know the difference.

It's kind of like saying "if mutt is already integrated enough with vim
that you can call vim from inside mutt, then it seems they've already
recognized the usefulness of integrating the two functions."  Sure it's
useful to integrate a mail reader and an editor.  In fact, mutt would be
kind of useless without vim or at least some substitute (emacs, nano).
But that doesn't mean that mutt should have a builtin editor.

I use scripts 'pack' and 'unpack', attached, for this purpose.

On Wed, Jul 07, 2004 at 10:51:29AM -0400, Stephen R Laniel wrote:
> Also, gzip has a -r option that does precisely what I
> thought bzip2 did. And bzip2 claims that its arguments
> resemble those of gzip, even though the former lacks -r.

gzip -r is very different from what it sounds like you want to do.

      gzip -r someDirectory/ 
      
         is equivalent to 
    
    gzip `find someDirectory/`

It is perhaps a bug in bzip2 that it doesn't have this simple option, of
course you can get the same effect with bzip2 `find someDirectory/`.
bzip2 doesn't claim to have identical arguments to gzip; just for those
arguments it does have it uses the same switches.

In any case, this is very different from tar, which is an archiver, like
its ancestor ar, and creates a single archive file with all the
directories within.  It's very nice to have archival and compression
functions separate--if you want to always use them together, use my
'pack' and 'unpack' scripts or tar cfj/xfj.  But tar, bzip2, and gzip are
of course pipeable and you might want to put different pieces in between
(e.g., filters, encryption, signing, etc.).  

As you may know, a DEB file is just an ar (archive) containing two tar.gz
files in there.  This transparency and ease of manipulation has saved me
headaches on numerous occasions; versus an RPM file which is just some
inscrutable self-contained package.
-- 
Adam Rosi-Kessel
http://adam.rosi-kessel.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.bostoncoop.net/pipermail/linux-disciples/attachments/20040707/cfabd161/attachment-0001.pgp


More information about the Linux-disciples mailing list