Oh, bad ideas coming from The Camel aren't suddenly good ideas. I realize that the "these two magic numbers are good magic numbers" confusion has been well-entrenched in much of the Perl world.

By the same (seductive but twisted) logic that one should use "\012" not "\n": Then one should also note that an SMTP server is expecting "HELO" in ASCII, not EBCDIC nor UTF-16 nor any number of other encodings. Since 'the value of "H" clearly varies when you consider EBCDIC versions of Perl', it is clear that the only correct thing to do is to hard-code the magic numbers of '"HELO" in ASCII' and write "\x48\x45\x4c\x4f" instead (except that represents character code points not bytes so you better do even more torturous hoop jumping to make your code portable, but let's not discuss that further). That will make for much more portable code.

the local concept of "newline"

Note that what character "\n" is has much less to do with the local line-endings than perlport might confuse one into believing. "\n" is a local linefeed character (always just one) which will often be translated to/from a "newline" (which may be more than one character or even meta data instead of being any characters at all) when read/written certain places (to/from a file in Win32, to/from some devices in Unix, via RMS in VMS, etc.). Don't let the "n" fool you; "\n" isn't a "local newline sequence".

"\n" is just plain ASCII LF on every ASCII system except an old Mac which made the mistake of being "nearly ASCII" while trying to avoid the "translate to ASCII" layers that non-ASCII systems wisely put into place. And old-Mac Perl made the mistake of following old-Mac C's mistake with regard to "\n" and "\r". So if you want to work on old Mac Perl and are doing something beyond reading/writing text files, then you get stuck working around this misdesign of making "\r" not be a Carriage Return. But that doesn't make "\n" "local newline", it just makes "\n" "broken on old Macs except for in local text" (or so). "\n" isn't CR+LF on Win32 (which is what the "local newline" is on Win32). "\n" is useful for getting the "local newline" when writing in text mode.

"\r" is clearly meant to be "carriage Return" so it makes no sense for it to be ASCII LF on a Mac not ASCII CR. The use of "n" in "\n" makes it somewhat less clear, unfortunately, but "\n" is the best thing to use when you want a LF character (except on old Macs). So if you use something other than "\n" to get a LF, then you should make it clear why:

my $lf= "\n";
# "\n" eq ASCII CR implies an old Mac so "\r" is ASCII LF:
$lf= "\r"  if  $lf eq "\xC";
[download]

Because this "hard-code the magic numbers" meme is poisoning our youth. :)

It'd be cool if Perl 6 would commit to making "\r" actually mean CR if anybody ever ports Perl 6 to an old Mac so we can have a clear line to put an end to this bad (but practical) idea and all of us return to eschewing the hard-coding of magic numbers.