Re: [PATCH] uudecode doesn't work on files with DOS line endings

[Paul Eggert]

Bruce Korb <address@hidden> writes:

> Let's assume that it was POSIX' intent to require that the text end
> with exactly the four character sequence 'e', 'n', 'd' and '\n'.
> What is the effect of allowing an extra '\r' slipped in there?

Well, strictly speaking, that means that the input shouldn't be
recognized as the output of uuencode, and should therefore be treated
like random data and rejected.  And this should happen with \r values
everywhere.  In this sense, trailing \r should be treated like any
other random string.

For example, suppose someone appends the string "foobar" to every line
that is input to uudecode.  What should happen?  E.g.:

uuencode /bin/sh /bin/sh | sed 's/$/foobar/' | uudecode -o sh

POSIX says that the input to uudecode is not in uuencode format, so
uudecode shouldn't find anything.  That is, the program should behave
just as this one does:

uuencode /bin/sh /bin/sh | sed 's/^/foobar/' | uudecode -o sh

But that's not how either GNU or Solaris uudecode behave.  Both of
them decode the first usage (albeit with the diagnostic that prompted
this thread), and refused to decode the second one.

> The only thing that might break is someone's application that was
> expecting to find a failure, yes?

Yes, most likely.  I guess the question is whether someone can
reliably use uudecode to test whether an input file is in uuencode
format.  (The answer seems to be "no".  :-)

> BTW, should I file an aardvark?

Probably, once you figure out what you want uudecode to do.

I just checked, and FreeBSD uudecode allows \r after "end", so that's
an argument for installing this change.