Path: utzoo!attcan!utgpu!watmath!att!ucbvax!bloom-beacon!athena.mit.edu!tytso From: tytso@athena.mit.edu (Theodore Y. Tso) Newsgroups: comp.sources.d Subject: Re: Why "shar: Shell Archive (v1.22)" is bad Message-ID: <14502@bloom-beacon.MIT.EDU> Date: 21 Sep 89 21:27:10 GMT References: <1979@prune.bbn.com> <444@crdos1.crd.ge.COM> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: tytso@athena.mit.edu (Theodore Y. Tso) Organization: Massachusetts Institute of Technology Lines: 44 In article <444@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >| There are two reasons for this: >| 1. It generates complex /bin/sh constructs: > [ example deleted ] >| my shell parser can't parse this, and I doubt any non-sh >| parser can. > It was intended to work with the UNIX /bin/sh program, not a subset >which some people don't have. It works with versions back to at least V7. Even if some people have /bin/sh, they may not want to use it. After all, shar archives are such a huge potential security hole. I would feel much safer using a parser that didn't allow such constructs as "(/bin/rm -rf /) &". This is a fair request to make, in any case. What about people running MS-DOS that want to unshar a source kit? Why force them to suffer more than they already have to? (Not running a real operating system should be punishment enough! :-) >| >| 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. > After unpacking many things which had "all arrived but one" I think >that "waste of time" may be a matter of opinion. It's a consequence of >splitting files to make equal size archives rather than doing an >aproximation with whole size. Of course, the other obvious question is what is it so important to have equal size archives? The cost of having a couple of 47k or 48k archive files instead of all 50k seems to be a small price to pay for being able to get the files before you get all of the archives. This is particularily true for packages which get broken up into a large number of pieces. Another suggestion: someone should write a shar which can break up files into several pieces (although it should try very hard to rearrange files to make things the right length) and which generate shar files that unwrap partial files and, when a shar file detects that all the pieces of a particular partial file have been unwrapped, puts it together automatically. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!