lwv27@cas.BITNET (07/12/90)
So what steps must one take to make their C code and shars portable to
all the environments which might have an interest.
1. You must keep your source lines less than 78 characters long at ALL time
Since this INCLUDES after shar, you probably want a few shorter.
Reason: I get email via bitnet (such as requesting files from archives),
and find that some sites throw away all characters after 79 or 80.
2. You must NEVER use curley brackets. Instead, you will need to require
the user to use ANSI C and then code all of your C using trigraphs.
Of course, if you needed the brackets in a SHELL or other language,
I guess you are out of luck.
Reason: some sites translate the curley bracket into a square bracket -
but leave the square brackets alone.
3. You must never have embedded control characters, including tabs.
Reason: I have seen tabs turned into spaces (not too bad) and control
characters deleted (VERY bad). If your code or doc need these in
them, you are out of luck.
4. Your shar must not use any unique shell or commands. Nothing csh or
ksh specific for example can be in the shar.
Reason: This requirement is only if you want folks on a system other
than yours to be able to easily unshar the programs.
5. Your file names and variable names should be kept small and single
case.
Reason: Again, this is only if you want folks on a system other
than yours to be able to easily unshar them. If the shar is
not careful, and instead trys to output to Read.Me.First for example,
the MS-DOS folks are probably going to be out of luck. On the other
hand, if a VMS shar using ABC$USER tries to be unshared on a Unix
system, you might get surprised if the shar is not careful in quoting
the file names.
6. Each part of your distribute should be kept to 60k or less.
Reason: Some sites refuse to pass mail items greater than this.
Okay - there is a start. What other rules are needed? Anyone want to add these
to a monthly posting to comp.sources.d ???
--
Larry W. Virden
Business: UUCP: osu-cis!chemabs!lwv27 INET: lwv27%cas.BITNET@CUNYVM.CUNY.Edu
Personal: 674 Falls Place, Reynoldsburg,OH 43068-1614
Proline: lvirden@pro-tcc.cts.com America Online: lvirden CIS: [75046,606]gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (07/12/90)
In article <9007121205.AA07748@jade.berkeley.edu> lwv27@cas.BITNET writes: >6. Each part of your distribute should be kept to 60k or less. > > Reason: Some sites refuse to pass mail items greater than this. Compu$erve won't pass mail that is more than 50k for their non-commercial users. Some UUCP sites won't pass mail bigger than 32k. 7. Make sure your shar contains no trailing spaces. Some mailers eat trailing spaces. -- "Perhaps I'm commenting a bit cynically, but I think I'm qualified to." - Dan Bernstein
chip@tct.uucp (Chip Salzenberg) (07/13/90)
According to lwv27@cas.BITNET: >1. You must keep your source lines less than 78 characters [...] >2. You must NEVER use curley brackets. >3. You must never have embedded control characters, including tabs. >4. Your shar must not use any unique shell or commands. >5. Your file names and variable names should be kept small and single case. >6. Each part of your distribute should be kept to 60k or less. I'm supposed to do all this just because some sites have software that is so badly broken they can't even pass articles along verbatim? Didn't anyone on BITNET think of passing articles along in ASCII and translating them AFTER retransmitting them? No way, dudes. If BITNET can't handle my sources code verbatim, then BITNET can go rot. -- Chip, the new t.b answer man <chip@tct.uucp>, <uunet!ateng!tct!chip>
louie@sayshell.umd.edu (Louis A. Mamakos) (07/13/90)
In article <9007121205.AA07748@jade.berkeley.edu> lwv27@cas.BITNET writes: >2. You must NEVER use curley brackets. Instead, you will need to require > the user to use ANSI C and then code all of your C using trigraphs. > > Of course, if you needed the brackets in a SHELL or other language, > I guess you are out of luck. > > Reason: some sites translate the curley bracket into a square bracket - > but leave the square brackets alone. Don't use curly braces in a C program? Get real. If the BITNET folks want to participate in USENET, perhaps they should fix their transport software to not muck the data, or at least make the translations invertable. louie
rsalz@bbn.com (Rich Salz) (07/14/90)
Here's the rules I try to follow: 1. Screw EBCDIC -- use ASCII or ISO whatever-it-is. 2. Assume a reasonably clean transport mechanism, but try to detect errors. 3. Keep it under 60K. 4. Avoid control characters, except for ^I ^L and perhaps ^H. 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. Posting anything other than human-readable sourcecode to a sources newsgroup is a crime. Your not-so-humble-c.s.unix-moderator, who is about to go on a much-needed vacation. /rich $alz -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
clewis@eci386.uucp (Chris Lewis) (07/19/90)
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