Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!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: Existing feature requested Message-ID: <495@crdos1.crd.ge.COM> Date: 25 Sep 89 18:44:22 GMT References: <14502@bloom-beacon.MIT.EDU> <4155@cbnewsh.ATT.COM> Reply-To: davidsen@crdos1.UUCP (bill davidsen) Organization: GE Corp R&D Center Lines: 25 In article <4155@cbnewsh.ATT.COM>, wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) writes: | ]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 | | Has anyone written someting like this? The general case is | a knapsack / bin-packing problem that takes a list of items | and outputs a bunch of lists each containing less than N KB. | Implementation issues include output formats, and whether sizes | belong in the input or should be determined by the bin-packer. The default behavior of shar2 (up to v1.25 now) is to break up the total collection of data into M files of size S each. I usually roll mine to be about 50k, allowing headers, etc, to be added without hitting the magic 64k limit. shar2 handles text, binary, or a mixture thereof, using automatic recognition or manual specification of binary files. -- 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