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