|Problems? Is your data what you think it is?|
Also a bit of history: Wiki CRLF history. This is extra info - some folks find it interesting.
Many moons ago I worked with these ASR33 teletypes. In order to see one now, you'd have to go to a museum or watch an old black and white film. These things used paper tape which had lubricating oil embedded in the tape. On the keyboard, on the right, there were 3 keys arranged together: Carriage return (CR), Line Feed (LF) and rubout (NULL) (not just a single "return" or "enter" button). The paper tape was 8 bits wide, a NULL meant to punch holes in all 8 positions. The normal sequence to end a line was: CR, LF, Rubout.
I'm not sure that I buy all of the explanation in the wiki article. The ASR33 was a very stupid thing and I think part of the reason was to just have a separate key for each mechanical action (eg separate CR from LF). This also allowed low resolution pictures of a sort to be printed by repeatedly printing over the same line (no LF). I saw many pictures printed like this so, the Wiki theory that LF was needed as time delay for the CR mechanics is doubtful - there was hardware flow control. The lubrication for the mechanical fingers came from the tape itself, so the periodic Rubout after every line served to keep all of the fingers well lubricated. A series of rubouts served to indicate the preamble and postamble to a tape. Nasty stuff as all the folks dealing with these oil soaked tapes wound up with grease stains in their shirt pockets! We viewed optical tape readers as a major technological advance! No more oil in the tape and therefore no more grease stains in the shirt pockets!
On a more practical side of things, I exchange programs from my Windows box to Unix and vice-versa. Last month I wrote 2 Perl files on Unix with vi and one Perl file on Windows. Perl on either machine didn't care and the program ran on both machines (Perl doesn't care for its own program). I haven't had trouble with exchanging data files when Perl is doing the reading.
I use TextPad (a shareware program) for my Windows program editor and it doesn't care either. The trouble happens when you are exchanging data with something like Windows NotePad which does care (it cannot deal with just LF as a "newline" character). However a simple Perl program that chomps and then re-writes the line with a "\n" seems to set things right (results in \r\n when run on Windows and just \n when run on Unix).
So by and large, I figure that Perl did about as well as can be done with this mess.
If you are say hashing to disk with a fixed record size in bytes, this is certainly a consideration, but I've written multi-platform programs that work fine. This is a detail that matters, but there are solutions. But for the most part, this is not important at all, except when the output file is going to be used by a non-Perl application that can't deal with different line endings.