rmarks@KSP.Unisys.COM (Richard Marks) (09/27/89)
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
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/27/89)
In article <716@bbking.KSP.Unisys.COM>, rmarks@KSP.Unisys.COM (Richard Marks) writes: | FLAME ON! | [ explanation of DOS uudecode problems and proposed fix/enhancement ] | | A better way would be for Rahul to use one of four other encoder's | that generate acceptable lines. | FLAME OFF! But he already said that this was a teething pain and would be fixed. In the meantime we can fix it by hand or use a standard UNIX uudecode. Why the FLAME at all? The problem has been acknowleged. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
svirsky@ttidca.TTI.COM (Bill Svirsky) (09/29/89)
In article <716@bbking.KSP.Unisys.COM> rmarks@KSP.Unisys.COM (Richard Marks) writes:
+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.
Whatever happened to the UUENCODE program that would place a table of
the characters used for encoding in front of the 'begin' line. The
corresponding UUDECODE would then check this table before decoding to
see if any of the characters had been changed. If any had, it would
alter its decoding strategy to utilize the new characters. The beauty
of it was, that since the table was placed before the 'begin' line, it
was completely compatible with older versions of UUDECODE which would
just ignore it.
--
Bill Svirsky, Citicorp+TTI, 3100 Ocean Park Blvd., Santa Monica, CA 90405
Work phone: 213-450-9111 x2597
svirsky@ttidca.tti.com | ...!{csun,psivax,rdlvax,retix}!ttidca!svirsky