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.