Package: uudeview Version: 0.5.15-4 Severity: normal Hi, I recently decoded an file with uudeview that had DOS line endings in it, however, I didn't find this out until later when I had problems reading the file (it was a shell script). So, a the very least, uudeview should print a warning when the end-of-line sequence in the decoded file is different from the native (target) operating system's end-of-line sequence. Also, an option should be made available to instruct uudeview to automatically convert to the native operating system's end-of-line sequence. Thanks,
Here'a another bug report. I haven't done anything about this.
Chris Hanson wrote: How was the file encoded? If it was "encoded" as plain text or quoted printable, then I agree that this would be a bug - but I think UUDeview does already use the native end of line marker when writing plain text or quoted printable files. If the file was sent using one of the binary encodings, then I strongly disagree. UUDeview is not supposed to look at a file's contents, and should under no circumstances touch that data. Frank
Here's the reply from the upstream maintainer. Can the two of you please figure out the right action? Chris
Chris Hanson writes:
> Here's the reply from the upstream maintainer. Can the two of you
> please figure out the right action?
>
> Chris
> Date: Fri, 12 Apr 2002 09:58:34 +0200
> From: 520065607613-0001@t-online.de (Frank Pilhofer)
> To: Chris Hanson <cph@zurich.ai.mit.edu>
> Cc: 124049-forwarded@bugs.debian.org
> Subject: Re: uudeview: needs an option to convert CR/LF to native mode
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Chris Hanson wrote:
> >
> > Here'a another bug report. I haven't done anything about this.
> >
> > Subject: Bug#124049: uudeview: needs an option to convert CR/LF to native mode (for UNIX - LF)
> >
> > I recently decoded an file with uudeview that had DOS line endings
> > in it, however, I didn't find this out until later when I had
> > problems reading the file (it was a shell script).
> >
> > Also, an option should be made available to instruct uudeview to
> > automatically convert to the native operating system's end-of-line
> > sequence.
> >
>
> How was the file encoded? If it was "encoded" as plain text or quoted
> printable, then I agree that this would be a bug - but I think UUDeview
> does already use the native end of line marker when writing plain text
> or quoted printable files.
Here is a typescript of the relevant header,
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sendmailconfig
Content-Transfer-Encoding: BASE64
>
> If the file was sent using one of the binary encodings, then I strongly
> disagree. UUDeview is not supposed to look at a file's contents, and should
> under no circumstances touch that data.
>
> Frank
>
According to my understanding of RFC-1341, especially see its
Appendix H, the encoded text for the above referenced header must
have its line endings converted to canonical form (ie, CRLF) prior
to performing the base64 encoding, which is indeed the case.
Therefore, upon decoding that data, the canonical form line
endings should be converted to native line endings. This is
exactly the jist of my originally submitted bug report.
So, even though the encoding is of a binary type (base64), since
the content-type is "text/plain", the rules in RFC-1341, Appendix
H, must be followed.
>
>
> --
> Frank Pilhofer ........................................... fp@fpx.de
> The great advantage of compact cars is that you can get twice as
> many of them into traffic jams. - Alfred E. Neuman
Hi Frank, Does this help? Can you guys straighten this out between you? Just leave the "124049@bugs.debian.org" address on your messages so that there is a record of what happens (and so I can follow along). Thanks, Chris
Chris Hanson wrote: I see. I agree that you have a point here. However, I don't know if there is anything that I *should* do: I've also seen messages that have binary content, Base64 encoded, and which erroneously claimed to have a "text/*" content type. Fixing the behavior for your message would do greater harm to these other (broken) messages. UUDeview already has a "More MIME" option (-z), so if I were to do anything, I'd just do it if this option was set. Of course, I'd prefer a patch ;) Frank
Date: Mon, 15 Apr 2002 10:10:38 +0200
From: 520065607613-0001@t-online.de (Frank Pilhofer)
Chris Hanson wrote:
>
> > How was the file encoded? If it was "encoded" as plain text or quoted
> > printable, then I agree that this would be a bug - but I think UUDeview
> > does already use the native end of line marker when writing plain text
> > or quoted printable files.
>
> Here is a typescript of the relevant header,
>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; name=sendmailconfig
> Content-Transfer-Encoding: BASE64
>
I see. I agree that you have a point here. However, I don't know if
there is anything that I *should* do: I've also seen messages that
have binary content, Base64 encoded, and which erroneously claimed
to have a "text/*" content type. Fixing the behavior for your message
would do greater harm to these other (broken) messages.
UUDeview already has a "More MIME" option (-z), so if I were to do
anything, I'd just do it if this option was set.
Of course, I'd prefer a patch ;)
Although many MIME encoders do the wrong thing with BASE64 text/*
messages, the standard _requires_ "\r\n" line endings on all such
messages prior to encoding. uudeview does not correctly decode such
line endings, instead leaving them untranslated. So this doesn't have
anything to do with DOS encodings, and it is in fact the standard case
rather than an exception.
Let me look at this. I'll see if I can generate a patch for you.
I generated an example with correct encoding and have verified that it
decodes incorrectly.
Personally I feel that the default behavior should do the correct
thing with text messages. Mis-marked binaries should be handled
specially. But you're the author, so it's your call.
I'll get back to you when I have something definite.
Chris
Date: Mon, 15 Apr 2002 10:10:38 +0200
From: 520065607613-0001@t-online.de (Frank Pilhofer)
Of course, I'd prefer a patch ;)
Well, I can see where the fix has to go, but I am not certain how to
make the fix. Either UUDecodePart() or UUDecodeLine() should be
changed to do the translation. It is probably simplest to change
UUDecodeLine(), but it will need additional state to track dangling \r
characters where the \r\n pair is split across two encoded lines. I
am having a little trouble following the control flow in the program,
so it's not clear to me where the state should go.
It's also necessary to detect Content-Type, which is being done in
uuscan, but not in uunconc. That needs to go in UUDecodePart() and
the value passed into UUDecodeLine() somehow. The header is currently
detected but the value is ignored.
Can you fix this? Probably you can figure this out quickly, whereas
it will take me some time to get my head around this code. I'll send
you an example file if that will help.
Chris Hanson wrote: Sure, I may fix it sometime, but I don't know yet when I can again give some attention to UUDeview. Frank