765675 - On Linux, somehow DOS encoding is used for emails saved via File -> Save As

Status: RESOLVED DUPLICATE of bug 523577

(MailNews Core :: Backend, defect)

Description

[Martin Mokrejs]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120612 Firefox/13.0 SeaMonkey/2.10
Build ID: 20120612152337

Steps to reproduce:

When I select several emails from the mailer and do File -> Save As (actually "right click and Save As") then:

1. I thought I am asked for a filename to be entered. What a surprise the selected emails were stored into a directory with that name. Silly but I can live with that. Umm. The window says Choose a folder ... cant these be saved into a single RFC822 format or latter? ;-)

2. More importantly, it took me an hour to realize while my awk/grep scripts do not work fine with values extracted from these files. In the end, I found there are DOS carriage line returns \r\n. Therefore, my parsers included \r in the values and that was probably why they failed. After running dos2unix on the file things started working. Please do not write files on Unix in DOS encoding.

I am on Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120612 Firefox/13.0 SeaMonkey/2.10

Comment 1

[WADA:World Anti-bad-Duping Agency]

What is difference of your rquest from already opened Bug 523577?

If you couldn't find that bug by your search due to inappropriate bug summayy of that bug, change bug summary of that bug to appropriate one, please.

Comment 2

[Martin Mokrejs]

Thanks, I haven't found that bug #523577 while searching. It is not my bug so I will NOT change its subject line.

That bug explains than one is supposed to run dos2unix on .eml files. I don't understand why a Linux computer would ever write out something in DOS encoding unless explicitly asked. Write .eml files in DOS encoding is just bad idea, sorry.

It is a question who realizes those DOS line endings because as I said, sed/awk do not realize that so they include in the match also the \r, and that breaks because it possible get interpreted as \r\n somewhere in the bash. I parsed last field from the .eml file on some line, I think it picked up also \r. Then, that variable was to be a filename prefix and I appended to it ".txt". Bash complained that prefix does not exist (somehow the ".txt" was not considered) and the line was partially overwritten. I see now why. It interpreted the \r and moved backwards on the line. It is just silly.

less(s) nowadays doesn't tell you there are CRLF chars, only more(1) still show them. Or you can run "od -c" if you are brave and have already the suspicion. But in general this is cryptic.

I just don't agree with CRLF in .eml files on UNIX. I would it ignores system-wide settings.

BTW: I also think textutils/coreutils/whatever should not include \r in the match (say in awk '{print $9}' output).

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to Martin Mokrejs from comment #2)
> Write .eml files in DOS encoding is just bad idea, sorry.

The CRLF in .eml file is never DOS encoding by Tb. It's "line ending defined by mail protocol such as SMTP, POP3, IMAP", which is unfortunately same as DOS line ending instead of Linux line ending for you.
Have you read thru already opened bug 523577?

> I just don't agree with CRLF in .eml files on UNIX.

What is definition of ".eml file on Unix"?
Show us "Official definition of .eml file on Linux", please.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to Martin Mokrejs from comment #2)
> I haven't found that bug #523577 while searching.

Why you couldn't find that bug by your search? Due to inadequate bug summary?

> It is not my bug, so I will NOT change its subject line.

"Reporter of bug at bugzilla.mizilla.org" is never owner of the report. Reporter is merely a people who reported problem first or made crispy reort at B.M.O. Who found same problem can share the first/crispy bug report. So, there is no concept of "my bug" at B.M.O. "Reported:" field of bug is simply "Reportd: field".
Keeping different bug for same problem is usually useless for resolving/fixing problem. In such case, we usually close as DUP.