[comp.os.minix] Some thoughts on sending files

VBRANDT%DBNUAMA1.BITNET@cunyvm.cuny.edu (09/13/89)

Hello all,

   ... recently, someone complained about not being able to use stuff from this
newsgroup because he was on EARN/BITNET.  The suggested remedy was to use
uuencoding to mail files around.

   Well, I'm on EARN/BITNET, and I *don't* usually have problems.  I readily
admit that it has taken me some time to get to this stage, and it is not always
completely obvious at first.  But please: don't just sneer at IBM (which we all
like to do :-), think a little.  I have found that most trouble stems from the
IBM mainframe -> PC/ST/whatever download process.  Check out the exact EBCDIC
equivalents for the ASCII character codes and vice versa.  Make sure your
transfer software knows about those backslashes and curly braces.  Confirm that
a file transferred back and forth is identical to the original copy.

   I am against uuencoded files, because now I can look at the file, decide
whether I want to keep it, or simply discard it.  Using uuencoded transfer,
I'd have to decode everything first.  And, not everyone has uudecode on his/her
mainframe (yes, there's one for VM/CMS, and I have it :-).

   A notable exceptions are those files that absolutely *have* to contain lines
longer than 80 characters.  These lines get split, the remainder is wrapped to
the next line, thus creating problems when unSHARing things.  Please check your
postings if you really need those long lines before mailing them out.

   One thing that drives me mad, however, is the fact that many people send out
files containing TAB characters without letting us know how they had set their
tab stops.  While 4 is common, I like to use 8, and other people use still
other values.  Sometimes, one can figure it out from the context.  Some BITNET
gateways like to translate tabs.  My plea to all of you on ASCII machines:
Please include TAB stop info at the beginning of your files.   Better yet,
convert all tabs to spaces before mailing, and we BITNET people can convert
them back before unSHARing, thus giving us a better chance of getting the
same character counts on the SHARed files.

   The same goes for trailing white space, please remove it before SHARing
things.  It's generally good practice anyway.  I don't know any application
where trailing spaces are *essential* (with the notable exception of old-style
uuencoded files :-).

   A final note:  *IF* your submission refers ONLY to a SPECIFIC MACHINE that
runs Minix (like "help me, my AT HD does not work" ;-), please say so in the
subject line.  There's a lot of messages here, and I want to read all of them
that might concern me, and that takes a lot of time.  Thanks.

Guess I'm done now.  Flames discouraged.  Praise welcome. :-)

----------------------------------------------------------------------------
Bitnet:  VBRANDT@DBNUAMA1 (will go away late '89)      Volker A. Brandt
          UNM409@DBNRHRZ1 (soon)                       Angewandte Mathematik
UUCP:    ...!unido!DBNUAMA1.bitnet!vbrandt             (Bonn, West Germany)
ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU