Thank you.

So, just to hammer this home: in MacPerl the string "\n" really is "\x0D" -- and "\r" is "\x0A". This is not something the IO layers have anything to do with. A literal string containing "\r" or "\n" in MacPerl has a different value to the same string on, say, a Linux Perl. Gosh.

So, I suppose for MacPerl the IO layers must be capable of translating "\x0D\x0A" and "\x0A" to/from "\x0D" to allow for reading "foreign" files.

I confess I think it would be less confusing if "\n" meant "\x0A" at all times, and translation to/from system line-endings was relegated to the IO layers. So rather than "\n" being a "virtual" line ending (and "\r" being its dual), I think it would be clearer if the IO layer "normalised" line endings to "\x0A" AKA "\n" -- which is essentially what the DOS/Winders Perl does.

Ah well. There was something about this that didn't quite fit together, but without a Mac I could not pin down -- perhaps I couldn't see what the documentation was trying to tell me because I was refusing to believe in escape sequences with magical shape shifting properties :-(

Perl never ceases to amaze me.