Re^9: problem with 'bare LF' in script

I wasn't sure what it meant by "read "\r""

"read as" means "converted to when found in double-quoted string literals" here.

On MacPerl (Perl for old Macs), ord("\n") was 13, and ord("\r") was 10.
On Windows, unix and new Macs, ord("\n") is 10, and ord("\r") is 13.

Comment on Re^9: problem with 'bare LF' in script

Replies are listed 'Best First'.
Re^10: problem with 'bare LF' in script by gone2015 (Deacon) on Nov 13, 2008 at 10:51 UTC
So in at least two places the 5.10.0 documentation refers to the shape shifting properties of `"\n"` and `"\r"`. In 723298, above, you suggested: If any other odd systems need to be supported, it should be done by a PerlIO layer like it is in Windows. It's my opinion that the referenced section of perlport is outdated. Amen to the first. I'm left with the feeling, though, that on a practical level "you know and I know" that shape shifting `"\n"` is a thing of the past -- but short of an "official" (fully documented) change, it would be foolish to depend on this, strictly speaking. If I've misunderstood the position you'll let me know, I'm sure :-) I suppose one could beard the perl-porters in their lair ?	[reply] [d/l] [select]
Re^11: problem with 'bare LF' in script by ikegami (Patriarch) on Nov 13, 2008 at 14:08 UTC
On second thought, EBCIDIC systems probably use EBCIDIC LF and CR for \n and \r. The status of EBCIDIC Perl is "it works until someone tells us it doesn't". There hasn't been any testers or feedback from EBCIDIC users.	[reply]