Re: Re: Re: Re: Handling Mac, Unix, Win/DOS newlines at readtime...

[graff]

but what if a file was created on a Windows machine, but this code was being run on a Mac?

It wouldn't matter which type of system was running the perl code.

I remember reading somewhere in this thread that \r and \n have reversed semantics on the Mac (vs. *nix, Windows).

Um, no, that statement hasn't been made on this thread. My own experience has been that MS systems use "\r\n", all .n.x systems use "\n" and (older) Mac systems use "\r". Nobody uses "\n\r".

And now that MacOS-X is out with a unix foundation, maybe the number of variants will reduce to just two instead of three.

[IlyaM]

Nobody uses "\n\r".

This reminds me days when I just started using Perl. One of my first real scripts was supposed to handle both Unix and Win32 line endings in input text files. However one day it borked because of input file having "\n\r". No idea where such line ending came from though.

--
Ilya Martynov (http://martynov.org/)

[bart]

I remember reading somewhere in this thread that \r and \n have reversed semantics on the Mac (vs. *nix, Windows).

Um, no, that statement hasn't been made on this thread.

Oh yes it has. On a Mac, "\n" is "\015" (native end-of-lines), and "\r" is the other one, "\012". The sequences you can encounter, in Ascii, are matched by /\015\012|\015|\012/.

In addition, "\015\015\012" can occur too, in HTML pages you can download from the web, because of an erroneous FTP upload from Windows to Unix, as binary — and a download as text, which adds another CR.