Path: utzoo!attcan!telly!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.sources.d
Subject: Re: Portable C & shars (Was Re: compress - tar - uuencode)
Message-ID: <1990Jul18.215033.4248@eci386.uucp>
Date: 18 Jul 90 21:50:33 GMT
References: <9007121205.AA07748@jade.berkeley.edu> <2750@litchi.bbn.com>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Organization: Elegant Communications Inc.
Lines: 67

In article <2750@litchi.bbn.com> rsalz@bbn.com (Rich Salz) writes:
> Here's the rules I try to follow:

What he said...
 
> 1.  Screw EBCDIC -- use ASCII or ISO whatever-it-is.

If you've gone to all the trouble to compress uuencode your sources,
the BITNET people can't use it ANYWAYS, because it'll uuencode to ASCII
and they need EBCDIC.  And the EBCDIC->ASCII converters they have
locally available aren't likely to be any better than what the gateway's
using (one would hope...)

> 2.  Assume a reasonably clean transport mechanism, but try to detect errors.

Precisely.  Shipping text as text permits the gateways to do the "correct"
things.  Not all of them do, but it's their tough luck.

> 3.  Keep it under 60K.
> 4.  Avoid control characters, except for ^I ^L and perhaps ^H.

This is how you avoid most problems with 2.

> 5.  Keep your lines 80chars.

> This maximizes the chance that your software gets delivered, intact, to
> most systems on Usenet and off-shoot networks.  It also maximizes the
> value of your posting, since people can READ your posting, without pulling
> the whole thing over and unpacking it.

Precisely.  I'm the author of psroff, release 2.0 of which will be going
through comp.sources.unix shortly.  These are the rules I've used for
bundling.  In fact, psroff 2.0 I think is a good example of how to ship
such things, for there are a number of interesting wierdnesses about it
that exemplify how to bundle software in the difficult cases....

Eg:
    1) Lots of code emits arbitrary escape sequences with binary
       in them - I use backslash conventions in C, and some portable
       magic with shell scripts.
    2) I'm shipping binary font files.  Interestingly enough, even though
       some of these files are quite large, compress *can't* make them
       smaller.  So "uuencode | compress" would be a loss.  I was quite
       surprised to see that a PK encoded font file was actually smaller
       than a compressed SFP format version, and that compress refused
       to compress PK's.  Stranger still, if I were to compress and
       uuencode the *whole thing* (all 16 parts), it *still* wouldn't
       be any smaller.  Leaving it as is (shar, plus uuencoding of
       things that *have* to be uuencoded), gives inter-machine
       compressed batches the best chance to reduce the size because
       they don't have to uuencode again.
    3) I keep as much of my code below 80 characters as possible.
    4) I'm using Rich's new makekit package (currently in alpha -
       when are you going to release it?) that *tells* you about
       non-portable problems (trailing whitespace, characters that
       won't map thru bitnet properly, lines too long) etc, and
       will uuencode files that need it, but no other.
    5) Please put your README's first... ;-)

Frankly, whenever I see a compressed/uuencoded source distribution
I just hit the n key, especially since they usually come with
so little immediately-readable text.  And I suspect many others do
as well.  Such distributions are usually suggestive of code that's
not worth having, or if it was, it's not likely to be very portable.
-- 
Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list