Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001140 [1003.1(2008)/Issue 7] Shell and Utilities Editorial Clarification Requested 2017-05-17 08:08 2017-05-18 07:31
Reporter Villemoes View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Rasmus Villemoes
Organization
User Reference
Section uuencode/uudecode
Page Number
Line Number
Interp Status ---
Final Accepted Text
Summary 0001140: must the encoded output end with a zero-length line?
Description Both busybox' and GNU sharutils' uuencode end their output with a line consisting of a single "`" before the "end" line. However, if that line is lacking, GNU sharutils' uudecode fails to detect the "end" line and instead misinterprets the "end" line as a line of input:

$ printf 'foo' | uuencode '/dev/stdout' | grep -v '^`' | uudecode
uudecode fatal error:
standard input: Short filefoo8J

Busybox's uudecode correctly recovers the input.

Desired Action Clarify whether

begin 664 /dev/stdout
end

would be a conforming output from "printf '' | uuencode /dev/stdout" and/or whether this must be accepted as input by uudecode. More generally, must the "end" line be preceded by a line consisting of a single "`" character.
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0003692)
joerg (reporter)
2017-05-17 09:08

Looks like a bug in the GNU utilities.

With the UNIX uuencode, you get:

printf 'foo' | uuencode '/dev/stdout'
begin 644 /dev/stdout
#9F]O
 
end

and your example is decoded correctly.
(0003693)
stephane (reporter)
2017-05-17 10:10

Re: Note: 0003692

Note that the line before "end" in your output contains a single SPC character. So it's the same as the GNU output, but using the SPC character (0x20) instead of ` (0x60). SPC can cause problem for copy-pastes (at least) so is better avoided.

Both indicate an empty line (the first character indicates the length of the line). (0x60 - 0x20) & 0x3f is the same as (0x20 - 0x20) & 0x3f, that is zero.

I see nothing in the spec that mandates that trailing empty line, but all implementations seem to include it. On the decoding side, it sounds like a more reliable terminator than the "end" one, as a "end" could be found at the beginning of a uuencoded line (so a "end" on its own could be either the real end or indicate a truncated uuencoded file). IOW, relying on ` or SPC at the beginning of the line to mark the end of the file makes the detection of truncated files more reliable.

BTW, on an input like

begin 644 /dev/stdout
#9F]O
#9F]O
`
#9F]O
end


That is with lines of length 3, 3, 0, 3, GNU uudecode complains about the expected "end" not being found after that empty line.
(0003694)
stephane (reporter)
2017-05-17 10:20

In the BSDs, that extra empty line was apparently added in 1990, but without much of a comment or explanation:

https://github.com/weiss/original-bsd/commit/4bdd94feb49c37702585166528dd7f1061d27eb9#diff-5817be40429c877146c0008daac81672R118 [^]
(0003695)
stephane (reporter)
2017-05-17 10:27
edited on: 2017-05-17 10:39

Re: Note: 0003694

Sorry, that trailing empty line was always there. It's just that before that diff, that line would have been the encoding of the last fread() that returns 0 for EOF.

On the decoding side, it looks like BSD has always relied on that empty line instead of the "end" keyword (behaving like GNU). As far back as the original 1980 implementation in 4BSD

(0003696)
Villemoes (reporter)
2017-05-18 07:31

OK, if several uudecode implementations rely on a final

`


before end, and most (all?) uuencode implementations in practice produce that, I guess it would make sense to make that an explicit requirement.

Then there's the issue of such lines appearing before the end, which at least GNU uudecode chokes on. I don't think any reasonable uuencode could produce that, but it shouldn't hurt to explicitly ban it - that will also make the end detection even more robust.

- Issue History
Date Modified Username Field Change
2017-05-17 08:08 Villemoes New Issue
2017-05-17 08:08 Villemoes Status New => Under Review
2017-05-17 08:08 Villemoes Assigned To => ajosey
2017-05-17 08:08 Villemoes Name => Rasmus Villemoes
2017-05-17 08:08 Villemoes Section => uuencode/uudecode
2017-05-17 09:08 joerg Note Added: 0003692
2017-05-17 10:10 stephane Note Added: 0003693
2017-05-17 10:20 stephane Note Added: 0003694
2017-05-17 10:27 stephane Note Added: 0003695
2017-05-17 10:39 stephane Note Edited: 0003695
2017-05-18 07:31 Villemoes Note Added: 0003696


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker