tad@killer.UUCP (Tad Marko) (05/22/87)
I've been noticing a lot of people complaining lately about uuencoded files being screwed up by having trailing spaces removed. In a future version of uuencode, why can't the spaces either *always* be guaranteed to be there (ie. by being sealed in by a character that always marks the end of lines) or make a uudecode that doesn't need them (ie. it figures that since this line is short, it needs to be padded)? I can't imagine that either of these solutions would be very difficult except the former might cause some compatiblity problems until everyone got the new uudecode. Tad -- Tad Marko ..!ihnp4!killer!tad || ..!ihnp4!alamo!infoswx!ntvax!tad UNIX Connection BBS AT&T 3B2 North Texas State U. VAX 11/780 "Hi there!" -- Peter Gabriel in "Big Time"
emigh@ncsugn.ncsu.edu (Ted H. Emigh) (05/25/87)
In article <924@killer.UUCP> tad@killer.UUCP (Tad Marko) writes: >In a future >version of uuencode, why can't the spaces either *always* be guaranteed >to be there (ie. by being sealed in by a character that always marks >the end of lines) or make a uudecode that doesn't need them (ie. it >figures that since this line is short, it needs to be padded)? In the version of uuencode that I have (taken off the net some months ago) each line is given a checksum. This checksum is never a blank (as far as I can tell), so this problem should never arise with this version. In addition, we get a checksum to let us know when the file the we have has problems. -- Ted H. Emigh, Departments of Genetics & Statistics, NCSU, Raleigh, NC uucp: mcnc!ncsugn!emigh BITNET: NEMIGH@TUCC internet: emigh%ncsugn.ncsu.edu or @ncsuvx.ncsu.edu:emigh@ncsugn.ncsu.edu