Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!usc!srhqla!nrcvax!kosman!kevin From: kevin@kosman.UUCP (Kevin O'Gorman) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Freely-distributable uudecode for Unix Message-ID: <1054@kosman.UUCP> Date: 17 Dec 89 19:11:31 GMT References: Reply-To: kevin@kosman.UUCP (Root) Organization: K.O.'s Manor - Vital Computer Systems, Oxnard, CA 93035 Lines: 38 In article w8sdz@WSMR-SIMTEL20.ARMY.MIL (Keith Petersen) writes: >Some readers of this list have reported problems uudecoding files sent >by LISTSERV (or TRICKLE in Europe) which contain a "M" at the end of >each line and on the final line just before the "end" statement. > >The first character in each line defines the number of bytes of data >which follow on that line. If the uudecoder is working correctly the >trailing "M" should be ignored. It is added by LISTSERV to get around >problems of some mailers dropping trailing blanks. Some clarification is necessary, because this doesn't sound like the whole story. The UUDECODE and UUENCODE that I have on my clone works very well with the one on my UNIX machine. Neither of them is very happy with the files from SIMTEL20. The ones on MSDOS have a bunch of help screens that include this additional information: After explaining the basic encoding technique, they comment that since some mailers attempt to munge space characters in one way or another, all spaces are converted to back-tick (`) characters, which are not otherwise used in the encoding. The SIMTEL encoded does not seem to do this, and instead ends every line with an "M", which at least avoids problems with mailers that strip trailing blanks. They also comment that the last character of each line is a checksum, and explain a bit about how that is computed. The checksum falls in the same position used by the trailing "M" in the SIMTEL encodings, thus the decoders that I use think there's a checksum error on nearly every line. The one on MSDOS at least notices that this is happening very quickly and asks if I want to just ignore the checksum problems. I only have these two decoders to go by. I have no idea what's common in the BSD world, I can only guess how much like SYSV my software set is, so I'm not going to claim that this is the best and most modern stuff there is, but it sure sounds like a more robust scheme that what's being used at SIMTEL20. If it is also pretty standard, I would hope that SIMTEL20 would begin to use this scheme.