Path: utzoo!utgpu!watserv1!watmath!uunet!shelby!apple!mips!zaphod.mps.ohio-state.edu!wuarchive!mailrus!iuvax!rutgers!rochester!ken
From: ken@cs.rochester.edu (Ken Yap)
Newsgroups: unix-pc.general
Subject: Re: bsplit?
Message-ID: <1990Feb1.232040.26182@cs.rochester.edu>
Date: 1 Feb 90 23:20:40 GMT
References: <12897@cbnewsc.ATT.COM> <26143@cup.portal.com> <1990Jan23.040408.27311@banzai.PCC.COM> <26391@cup.portal.com> <1990Jan30.051455.7500@cs.rochester.edu> <26489@cup.portal.com>
Reply-To: ken@cs.rochester.edu
Organization: University of Rochester Computer Science Department
Lines: 41
Address: Rochester, NY 14627, (716) 275-1448

> 		for i in 1 2 3 4 5
> 		do
> 			dd bs=10k count=1 of=part$i
> 		done < foo

> 	Edit as appropriate.

> Nothing's "wrong" with the above; thanks for the example and posting!

> But, per "Edit as appropriate", one has to know beforehand how many parts
> the original will be split into, and, here's the clinker to the above, your
> example does NOT perserve sequential order if there are more than 9 parts
> such that one could do (later, when repacking after a uucp) "zcat part* | .."
> because "part10" collates after "part1" but BEFORE "part2".  In other words,
> an "ls part*" would sequence part1, part10, part2, part3, ... , part9  which
> is the incorrect order.

True. When I say edit as appropriate, I really mean add the bells and
whistles as needed. It would take very little shell hacking to add the
features you want.  Probably something along the lines of: get the size
from ls; loop, keeping track of the bytes written so far, a digits and
a tens counter (and a hundereds counter, if you're greedy); increment
as appropriate, exiting the loop when the size of the file has been
reached. Another approach would be to precompute the number of parts
needed and generate fixed width numbers by prepadding with zeros, then
trimming to the final width with sed. I can see some people retching in
the aisles now, but hey, sh scripts are easy to get working. :-)

I'm not against C bsplit in any way. I'd probably get that myself if I
needed that function. I just wanted to point out that sh and many other
Unix tools have lots of underused features* and that sometimes writing
a shell script is faster than hacking C.

No doubt somebody will suggest a perl version next. :-)

* Here's another example:

<foo exec

in a shell script will cause the rest of the script to read from file
foo. Similarly for >.