Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!eru!luth!sunic!dkuug!tidk!storm
From: storm@texas.dk (Kim F. Storm)
Newsgroups: comp.sources.d
Subject: Re: Why "shar: Shell Archive  (v1.22)" is bad
Message-ID: <419@texas.dk>
Date: 21 Sep 89 09:21:17 GMT
References: <1979@prune.bbn.com>
Organization: Texas Instruments, Denmark
Lines: 67

rsalz@bbn.com (Rich Salz) writes:

>    If at all possible, please don't submit sources to comp.sources.unix
>    that are generated with the above tool (I don't know it's common name,
>    it's not the RogueMonster one, it's not my cshar) -- the one that
>    uses s2_seq.tmp files to unpack things in sequence.

The tool in question is the shar2' archiver:

comp.sources.misc: Volume 3, Issue 14
Submitted-By: "Wm E. Davidsen" <davidsen@crdos1.UUCP>
Archive-Name: shar2
Date: 10 May 88 15:46:51 GMT

>There are two reasons for this:
>	1.  It generates complex /bin/sh constructs:
>	    my shell parser can't parse this, and I doubt any non-sh
>	    parser can.

True, and this should be corrected - even some Bourne shells have
problems unpacking these archives!

>	2.  If a piece is missing, the whole archive is useless until
>	    it shows up.  This is often a waste of time; you might as
>	    well let folks start examining the other files.

This is actually a very nice feature when you regard it from the
sender's point of view:  shar2 will make almost evenly sized articles
by splitting source files across archive parts.  This has two benefits:

a)  It generally produces fewer parts, and the fewer parts there are,
    the less risk there is that a part is lost.

b)  It enables you to send source files that are larger than 50-60 kbyte
    (or whatever you may think is a safe maximum for articles)
    *automatically* - and they will be concatenated automatically on
    the recipient end as well (when unpacking with /bin/sh).
    
The drawback is of course that parts must be unpacked in sequence.
The good thing about the shar2 archives is that this is enforced.

I have seen postings specifying that "You must unpack this part last",
because they contain commands to concatenate some files to yield
some large files, e.g.

	cat man.* > xyzzy.1
	rm man.*

Imagine that man.2 is missing because part 4 has not arrived, and you
choose to unpack part 7 despite the warning (if given at all)...
Where does man.1 and man.3 go, and will xyzzy.1 be a complete manual?
(the answer is left as an excercise to the reader :-)

I would like to see a replacement for shar2 which could

1) Reorder files according to their size to produce as few parts as
   possible (within a given maximum size).

2) Facilitate automatic split and concatenation of large files.

3) Allow "secure" unpacking, i.e. with a simple shell parser.

Is `cshar' the answer to my prayers?
-- 
Kim F. Storm        storm@texas.dk        Tel +45 429 174 00
Texas Instruments, Marielundvej 46E, DK-2730 Herlev, Denmark
	  No news is good news, but nn is better!