[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bz2 with tar
- To: tech_(_at_)_openbsd_(_dot_)_org
- Subject: Re: bz2 with tar
- From: Andreas Kahari <andreas_(_dot_)_kahari_(_at_)_gmail_(_dot_)_com>
- Date: Thu, 9 Dec 2004 15:56:22 +0000
- Reply-to: Andreas Kahari <andreas_(_dot_)_kahari_(_at_)_gmail_(_dot_)_com>
On Thu, 9 Dec 2004 16:20:38 +0100, Marc Espie <espie_(_at_)_nerim_(_dot_)_net> wrote:
> On Thu, Dec 09, 2004 at 09:55:20AM -0500, Michael Shalayeff wrote:
> > Making, drinking tea and reading an opus magnum from Michele 'mydecay' Marchetto:
> > > i choose the j option because it is also used by gtar to handle bz2
> > > files. I think there is no need to make things non-standard.
> >
> > there is no "standard" that specifies the "j" option
> > and thus who cares which joetar has it anyway...
>
> There is no standard that specifies tar anyways.
>
> Surprisingly enough, tar was not standardized by posix, nor
> single unix. They chose to go with pax.
I personally think that compression of the resulting achive is best
left to another utility. Decompression likewise. That's the Unix
philosophy after all. "Do one thing and do it well".
Part of the SUSv3 rationale for pax reads as follows:
No facility for data translation or filtering on a per-file basis is
included because the standard developers could not invent an interface
that would allow this in an efficient manner. If a filter, such as
encryption or compression, is to be applied to all the files, it is
more efficient to apply the filter to the entire archive as a single
file. The standard developers considered interfaces that would invoke
a shell script for each file going into or out of the archive, but the
system overhead in this approach was considered to be too high.
--
Andreas Kähäri
GnuPG: 1024D/C2E163CB
F4C4 A41A 665B 448A 3FA9 6AEA 12E3 39DA C2E1 63CB
Visit your host, monkey.org