Mac  CR   \015     \x0D     \r
DOS  CRLF \015\012 \x0D\x0A \r\n
*Nix LF   \012     \x0A     \n

2;0 juerd@ouranos:~$ perl -e'undef christmas'
Segmentation fault
2;139 juerd@ouranos:~$
[download]

Except he's using the end of line characters as a means of splitting the input.

--
perl -pe "s/\b;([st])/'\1/mg"

Did he? He did indeed.

Anyway, same regex (\r\n?|\n), other syntax (split /\r\n?|\n/, $foo).

I might have caused some confusing, I hope it'll be useful anyway :)

2;0 juerd@ouranos:~$ perl -e'undef christmas'
Segmentation fault
2;139 juerd@ouranos:~$
[download]

No, no, no!! $/ will be "\n" by default on Windows, just like it is (nearly?) everywhere else!

Yes, the default for $/ is \n on all platforms. The wicked thing is that \n isn't the same for all platforms. If you need to be sure about what character you'll get, use chr(), \xhex, \oct or \cchar.
If you don't know if your data came from the same platform as your script, you can only try using a regex like \r\n?|\n to match every known newline.

I quote from perlop:


All systems use the virtual "\n" to represent a line terminator, called a "newline". There is no such thing as an unvarying, physical newline character. It is only an illusion that the operating system, device drivers, C libraries, and Perl all conspire to preserve. Not all systems read "\r" as ASCII CR and "\n" as ASCII LF. For example, on a Mac, these are reversed, and on systems without line terminator, printing "\n" may emit no actual data. In general, use "\n" when you mean a "newline" for your system, but use the literal ASCII when you need an exact character. For example, most networking protocols expect and prefer a CR+LF ("\015\012" or "\cM\cJ") for line terminators, and although they often accept just "\012", they seldom tolerate just "\015". If you get in the habit of using "\n" for networking, you may be burned some day.

2;0 juerd@ouranos:~$ perl -e'undef christmas'
Segmentation fault
2;139 juerd@ouranos:~$
[download]

I'm not a big fan of the documentation you quoted. It muddles the distinction between processing of "\n" during I/O operations and the value of "\n" in a Perl string. This muddling helps lead to the confusion that we see several places in this thread.

"\n" is "\cJ" on nearly all platforms even though writing it to an I/O handle doesn't produce (just) "\cJ" on many platforms. "\n" could be any single character on a non-ASCII system. On an ASCII system, "\n" is "\cJ" except on (some?) Mac systems. But on Win32, writing "\n" actually sends either "\r\n" or "\n" depending on whether binmode is in effect. On VMS (which is an ASCII system, BTW), writing "\n" might not write any data to the file (but instead result in meta-data that denotes where the record ends), it all depends on the "structure" of the file in question (most files on VMS are not simply "streams").

        - tye (but my friends call me "Tye")

Okay so it's set to \n, but it *behaves* as though it's \n\r. Afterall chomp doesn;t leave the carriage return (you'd get no visibile output!)

--
perl -pe "s/\b;([st])/'\1/mg"

Or, if you're sure no \ns or \rs will appear in the middle of lines, you can do it even more simply: