Lots of heat, little light. (was: Unnecessary tar-compress-uuencodes)

[Kent Paul Dolan]

csu at alembic.acs.com (Dave Mack) writes:

>The supposed advantage in the case of the Anonymous Contact Service
>software which I recently posted to alt.sources is that the uuencoded
>compressed tar file was 135K, whereas the corresponding shar file is
>235K. Also, my version of shar3.24 died horribly when presented with
>a directory tree (I now have Rich Salz' cshar kit, including makekit,
>which solves almost all my problems, except that it insists on putting
>the README in the second kit.)

1) Part of the problem is that there are lots and lots of versions of
   "shar" and "unshar" around, only a few of which are reliable and
   handle all the nasty cases (try unsharing a tree with the shar
   files out of order) such as files which must be split, binary files,
   and so on, while "tar" is a reasonably standard program, however
   cumbersome.

>[...] my next release of the ACS will be in the form of shar files. As an 
>added bonus, all of the filenames will be under 14 characters in this
>one.

As a newbie to one of the systems that causes this concern, I note that
this isn't good enough.  If you want to be able to issue patch files
that work with "patch", you have to hold the file names down to 9 or fewer
characters so that the ".orig" extensions patch creates are respected,
rather than lost, making the original have the same name as, and therefore
clobber/be clobbered by the patched version.

>I cannot, however, guarantee that the README will be in Part01.

Not as big a deal as having shar create a file that calls for utilities
not present on my system.  (Hypothetical problem, so far.  ;-(  )

>Dave Mack
>embittered idealist, net.scum, villain, and commercial abuser of the
>net for over three days.

Hey, we knew that about you long before you posted ACS, Dave!  ;-)

Note also that the translation ASCII -> EBCDIC -> ASCII, especially
when the site doing the first translation is not the same as the
site doing the second, is not (necessarily) an identity transformation
even when the original is restricted to the 96 printable ASCII characters
plus newline.  Printable ASCII contains characters not present in EBCDIC
(and of course vice versa) and there is no standard pair of translation
tables.  Frankly, you're pushing your luck to try to get the alphabet
intact through a set of machines with different character encodings,
much less the whole printable character set.

Note also, whether compress-uuencode-compress saves or wastes bytes is
entirely dependent on the original data.  Rich $alz and I went around
about this one three years ago, and that is the only conclusion that
can be drawn; the argument is not worth rehashing in 1990.


Kent, the man from xanth.
<xanthian at Zorch.SF-Bay.ORG> <xanthian at well.sf.ca.us>
--
(member, "lonely old geezers with lap cats" posting cabel)