in reply to Re^6: problem with 'bare LF' in script
in thread problem with 'bare LF' in script

The only system that's different from unix these days is Windows. The conversion is disabled by :raw which should be used on a socket in the first place. 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.

Replies are listed 'Best First'.
Re^8: problem with 'bare LF' in script
by gone2015 (Deacon) on Nov 13, 2008 at 01:15 UTC

    perlop, under Quote-and-Quote-like-Operators, says:

    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.

    I wasn't sure what it meant by "read "\r"", but following GrandFather above I am now taking this to mean what "\r" is interpolated to, rather than what any IO read operation might be doing -- but I could be wrong... I've struggled to get my head around it so far :-(

      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.

        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 ?