From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <6a82af1edce3d3fa97b967d8e060b8b5@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] netpbm
From: Lucio De Re <lucio@proxima.alt.za>
Date: Mon,  7 Feb 2005 08:57:24 +0200
In-Reply-To: <bdfbe3b9d2659846a98a2bc5049016dd@plan9.ucalgary.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 040d1948-ead0-11e9-9d60-3106f5b1d025

> 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