|Anonymous | Login | Signup for a new account||2018-02-17 19:50 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|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|
|Final Accepted Text|
|Summary||0001140: must the encoded output end with a zero-length line?|
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.
begin 664 /dev/stdout
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.|
Looks like a bug in the GNU utilities.
With the UNIX uuencode, you get:
printf 'foo' | uuencode '/dev/stdout'
begin 644 /dev/stdout
and your example is decoded correctly.
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.
In the BSDs, that extra empty line was apparently added in 1990, but without much of a comment or explanation:
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
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.
|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|