Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!burdvax!bbking!rmarks From: rmarks@KSP.Unisys.COM (Richard Marks) Newsgroups: comp.binaries.ibm.pc.d Subject: UUDECODE 3.15 Message-ID: <716@bbking.KSP.Unisys.COM> Date: 26 Sep 89 17:50:52 GMT Organization: Unisys Corp. Knowledge Systems Projects Lines: 43 As most of you have discovered. My UUDECODE 3.07 cannot handle the current postings. The problem is a lowercase character at the end of each encoded line. When UUDECODE 3.07 sees the lowercase character, it assumes the line is text not encoded data. Until UUDECODE 3.15 is available, the fix is to remove this character. Then UUDECODE will give a bad section sum -r and size error. The sum -r and size for the resultant output file will be OK. UUDECODE 3.15 will accept this type of encoded line. It also is 50% faster. The speed up is because I recoded about 5% of the code in ASM. There is some moral here. FLAME ON! The idea behind UUENCODing is to get data over a minimal communications line. Such minimal lines may change lower to upper case, squish down multiple blanks, and do other horrible things to data. When UUDECODE 3.07 sees the lower case, it assumes the file is corrupt and quits. Probably a bit severe, but the assumption is that lower case is never on an encoded line. If there is some trivial corruption then the user will not want to decode, but will want to examine the file. Well now I have a case where some UUENCODE program is systematically putting lowercase in the file. Note the first line has a 'z', the next a 'y', etc. So 3.15 will check and validate this sequence. There are so many conditions with invalid sizes and counts that I was loath to accept any line with lowercase at the end. However I will enhance the "-l" option to UUDECODE to permit this sort of line to get thru with no line level checks. (Of course the sum -r and size checks will still be valid on the file level.) A better way would be for Rahul to use one of four other encoder's that generate acceptable lines. FLAME OFF! Regards Richard Marks rmarks@KSP.unisys.COM