Path: utzoo!attcan!uunet!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.sources.d
Subject: Re: Why "shar: Shell Archive  (v1.22)" is bad
Summary: Another misunderstood problem
Message-ID: <570@crdos1.crd.ge.COM>
Date: 27 Sep 89 19:14:31 GMT
References: <14502@bloom-beacon.MIT.EDU> <4155@cbnewsh.ATT.COM> <755@vector.Dallas.TX.US>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: GE Corp R&D Center
Lines: 33

In article <755@vector.Dallas.TX.US>, chip@vector.Dallas.TX.US (Chip Rosenthal) writes:

|  Here is the scenario.  I have an 8-part shar archive compressed and
|  stored in Part1.Z through Part8.Z.  I want to unshar it, using my
|  "safe unshar" program.  So I say:
|  
|  	% foreach file ( /archive_dir/Part?.Z )
|  	zcat $file | unshar
|  	end
|  
|  Braphz.  Outa luck.  Parts 2 through 8 won't extract because the required
|  stuff isn't in the directory where the unshar happens.

  Here's the scenario. There is a broken unshar which can't handle shell
commands. It fails and the shell script is blamed.

  I just tried exactly this, substituting /bin/sh for unshar and it
works fine. The sequence file is kept in the current directory. The
unpack is done in the current directory. No problems, no failure.

  If the problem is that your unshar can't handle the files, that's a
legitimate problem, but it will be better solved if the cause is
understood. shar2 produces complex shell scripts which do error
checking. If someone wants to have the ability to bypass the error
checking, that's a good idea, and I will probably put it in the new
version, via an environment variable, such as ERRCHK={yes,no,warn} or
some such. I don't intend to produce a version which doesn't produce
error checking code.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
"The world is filled with fools. They blindly follow their so-called
'reason' in the face of the church and common sense. Any fool can see
that the world is flat!" - anon