Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!texbell!vector!chip
From: chip@vector.Dallas.TX.US (Chip Rosenthal)
Newsgroups: comp.sources.d
Subject: Re: Why "shar: Shell Archive  (v1.22)" is bad
Message-ID: <759@vector.Dallas.TX.US>
Date: 30 Sep 89 00:01:39 GMT
References: <14502@bloom-beacon.MIT.EDU> <691@lakart.UUCP>
Reply-To: chip@vector.Dallas.TX.US (Chip Rosenthal)
Organization: Dallas Semiconductor
Lines: 28

In article <691@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes:
>Remember the KISS principle.

Absolutely.  I mentioned something to Bill in private email which
warrants consideration:

    The shar archive format should not be built for the convenience of
    the sender, but rather for the convenience of the receiver.

From this, follows the notion that the simpler the format the better.

There are all sorts of nice things which a shar archive can do
automatically:  concatonate files to big to fit in one archive reasonably,
automatically uudecode binary files, etc.  However, there is no reason
why these things need to be built into the archive.  Why not just provide
a "Runme.first" script which contains the few simple shell commands to
do these things?  A fancy shar program might build such a file
automatically.  This is more difficult than building these commands on
the fly and making them part of the archive, but that is trading off
sender (and shar author's) convenience for receiver convenience.

BTW, this isn't an absolute.  My own shar script does build in a
couple of things, like the clobber check and unpack check via "wc".
Like any engineering activity, there are tradeoffs when you decide
which features to use and which to leave out.
-- 
Chip Rosenthal / chip@vector.Dallas.TX.US / Dallas Semiconductor / 214-450-5337
Someday the whole country will be one big "Metroplex" - Zippy's friend Griffy