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