Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!iuvax!iucs!bobmon
From: bobmon@iucs.UUCP (RAMontante [condition that I not be identified])
Newsgroups: comp.sys.ibm.pc
Subject: Where to uudecode? (was Re: EOF markers (was: Extracting ARC...))
Message-ID: <4765@iucs.UUCP>
Date: Sat, 5-Dec-87 17:39:37 EST
Article-I.D.: iucs.4765
Posted: Sat Dec  5 17:39:37 1987
Date-Received: Thu, 10-Dec-87 20:08:00 EST
References: <3994@bellcore.bellcore.com> <4330015@hpindda.HP.COM>
Reply-To: bobmon@iucs.UUCP (RAMontante [condition that I not be identified])
Organization: Indiana University, Bloomington
Lines: 23

hardin@hpindda.HP.COM (John Hardin) writes:
>> / hpindda:comp.sys.ibm.pc / tr@wind.bellcore.com (tom reingold) 
>>
>>                          ... you should NOT uudecode on the PC end,
>> because uudecode translates literally.  So if you did, and if, for
>> some reason there was text in the uudecoded file, you would have
>> to add Returns in before the Newlines.  
>
>							[...]  I have
>used a number of PC uudecode programs on the PC (all grabbed from
>the net) and all seem to work just fine.  Seems like this should
>not be so if you are correct.

If the (text or other) file was originally uuencoded on an MSDOS beast,
then the CR/LF business should be consistent if uudecoded on one too.
Conversely, I occasionally find myself in vi, looking at a file with a
^M at the end of every line.

I have a stronger reason for shipping uuencoded files:  the combination of
C-kermit and ProComm transmit binary code VERY slowly relative to text-file
transmissions.  (This may be true for other kermits, I don't know.)  The
speed loss outweighs the additional time required to transmit a somewhat
larger uuencoded file.