From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] netpbm
Date: Mon, 7 Feb 2005 08:57:24 +0200 [thread overview]
Message-ID: <6a82af1edce3d3fa97b967d8e060b8b5@proxima.alt.za> (raw)
In-Reply-To: <bdfbe3b9d2659846a98a2bc5049016dd@plan9.ucalgary.ca>
> whoever wrote it made a nice job explaining why it's pointless to hack
> tar adding z (gzip/gunzip) and j (bzip2/bunzip2) options...
There's plenty of room for disagreement here:
- The pipeline is not reserved for the shell's sole use.
TAR can spawn a decompressor and read its output
without user intervention. The shell's contribution
here would be the ease of change. Casting it in TAR
stone may (usefully ot otherwise) discourage
enhancements (it didn't when Bzip2 was introduced).
- Anything more complex than a pipe isn't suitable for purely command line use.
TAR can inspect the archive and determine its format
(it's a published header), selecting the most
appropriate tool for decompression. My suggestion was
to move the identification into the decompressors, but
in this case we're merely extending TAR's existing
capabilities. Whether the filename suffix is a
suitable discriminator is for some other jury. PAX,
unless I'm mistaken, will even choose TAR or CPIO as
the archiver, which is commendable if one is looking
for simplification in a different realm.
- One can push the principle to breaking point.
"One task, one program". By that token, there ought
to be a TAR and an UNTAR as I don't see them as
equivalent. In fact fa/tarfs (or whatever) is a case
in point and I have no reservations in this regard.
But one can shift the "task" definition, too. There
are hundreds of archive formats, all in some use and
having to be familiar with each is painful. A utility
that subsumes at least the extraction process into a
single operation is not to be sneered at. Of course,
one has to be realistic, too.
In my opinion, the "one task, one program" principle is very sensible
for modelling and should only be abandoned when the components have
been so carefully tested that it is possible to combine them together
without major unpredictable problems being created. Programming
skills have a great influence here: I would trust Geoff's
multi-purpose TAR more than I would trust my own simple attempt at a
TAR implementation.
++L
next prev parent reply other threads:[~2005-02-07 6:57 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-04 5:45 tapique
2005-02-04 7:00 ` arisawa
2005-02-04 7:17 ` Lucio De Re
2005-02-04 8:06 ` geoff
2005-02-04 9:06 ` Lucio De Re
2005-02-04 9:13 ` Lucio De Re
2005-02-04 21:38 ` boyd, rounin
2005-02-05 1:35 ` geoff
2005-02-05 1:41 ` andrey mirtchovski
2005-02-05 1:45 ` geoff
2005-02-05 1:47 ` geoff
2005-02-05 6:19 ` Bruce Ellis
2005-02-04 8:52 ` arisawa
2005-02-04 9:03 ` arisawa
2005-02-04 9:16 ` Lucio De Re
2005-02-04 14:07 ` arisawa
2005-02-04 14:32 ` Sam
2005-02-04 15:54 ` andrey mirtchovski
2005-02-07 6:57 ` Lucio De Re [this message]
2005-02-04 9:31 ` C H Forsyth
2005-02-04 9:33 ` Tiit Lankots
2005-02-04 16:47 ` Derek Fawcus
2005-02-04 16:49 ` Ronald G. Minnich
2005-02-04 16:52 ` Charles Forsyth
2005-02-04 21:45 ` boyd, rounin
2005-02-04 22:02 ` Ronald G. Minnich
2005-02-04 22:08 ` boyd, rounin
2005-02-05 18:26 ` [9fans] factotum & invalid entries Tiit Lankots
2005-02-05 20:12 ` Russ Cox
2005-02-04 12:32 ` [9fans] netpbm arisawa
2005-02-04 14:00 ` arisawa
-- strict thread matches above, loose matches on Subject: below --
2005-02-10 15:24 tapique
2005-02-10 14:26 tapique
2005-01-27 12:40 cej
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6a82af1edce3d3fa97b967d8e060b8b5@proxima.alt.za \
--to=lucio@proxima.alt.za \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).