ked@garnet.berkeley.edu (Earl H. Kinmonth) (08/10/88)
Every segment of the recent mskermit posting arrived here with the
uuencode files botched whenever an encoded line ended in a blank. I
went through and repaired files by hand, but still could not get a
whole set that would unARC successfully.
As an historian, I probably will get holy drek from the experts, but it
seems to me that such monstrous items should be broken into logical
portions, compressed, and then encoded, rather than being mashed into
one block, compressed, and encoded. In other words do the documentation
as one group, the executable as another, the supplementary functions as
yet another, etc. With the monster block approach and the use of ARC,
one botched uuencode line seems to botch everything susbsequent.
Second, if these things must be encoded, why not use a base 85 encoding
rather than uuencode? The latter expands the text by something like
one-third, the former by something like one-quarter. PD base 85
en/decoders are available. If you don't like the one that comes with
compress (atob, btoa), I've written my own that works happily on a
number of machines.
E H. Kinmonth, Hist. Dept., Univ. of Ca., Davis Davis, Ca. 95616
916-752-1636/0776
Internet: ehkinmonth@ucdavis.edu
cck@deneb.ucdavis.edu
BITNET: ehkinmonth@ucdavis
UUCP: {ucbvax, lll-crg}!ucdavis!ehkinmonth
{ucbvax, lll-crg}!ucdavis!deneb!cck