in reply to 3 questions... 2 about newlines, and one on how to be NICE

There's a long section on this is the perlport manpage (perl portability).

The "\n" is just a representation of an actual bit pattern, and that bit pattern my be different from system to system. It's a "logical newline", so it ends up being what that system needs as a newline.

Some things that really care about the bit patterns (such as protocol modules) sometimes specify the exact bit sequence they want instead of relying on a logical representation. 

# from CGI.pm

$EBCDIC = "\t" ne "\011";
if ($OS eq 'VMS') {
  $CRLF = "\n";
} elsif ($EBCDIC) {
  $CRLF= "\r\n";
} else {
  $CRLF = "\015\012";
}

[download]

As for annotating the end of your problem, you could post a thank you with a summary of which answers helped you figure out the solution (or even which didn't). :)

--
brian d foy <bdfoy@cpan.org>

Replies are listed 'Best First'.
Re^2: 3 questions... 2 about newlines, and one on how to be NICE (bad rumors)
by tye (Sage) on Jan 11, 2005 at 04:02 UTC

    Calling "\n" a "logical newline" like you have, and like some versions of perlport do, does more to confuse than to enlighten.

    That same logic would call "a" a "logical lower-case letter A" that actually represents a bit pattern that varies from place to place. So, sometimes, if you want a specific bit pattern, then you should hard-code the bit pattern and not use "a" directly (insert here code that sometimes sets $a to be a specific bit pattern, etc. and then uses "$h$e$l$l$o" instead of "hello" to be "portable").

    It sounds good and is even correct to some extent. But it leads to people writing less portable code and a lot of confusion.

    See Re^4: Line Feeds (rumor control) for much about this.

    The code you quote is 50% due to a design mistake in the C compiler on old Macs that got propogated into Perl on that platform. The other 50% is due to a quirk of the most common VMS-based web server.

    None of it is based on general principles of portability, which call for just using "\n" which is simply "the newline character in that system's character set". Needing to use something other than that as newline simply means that your system is either missing a translation layer it should have (old Macs) or has extra translation it shouldn't have (the most common VMS web server).

    The comments in that code are a bit misleading as well. A better version would be: 

    if ($OS eq 'VMS') {
  # VMS web servers translate this to CR+LF
  $CRLF = "\n";
} elsif ("\r\n" eq "\012\015") {
  # Old Macs get CR and LF backward
  $CRLF= "\n\r";
} else {
  # This works on any sane system
  # whether EBCDIC or ASCII or other
  $CRLF= "\r\n";
}

    [download]

    The "logcial newline" idea confuses translations of newlines in I/O that are common to C-based systems (including Unix) with the above Mac mistake. It confuses the newline character with the end-of-line sequence. It encourages bad practices that happen to work on Macs and ASCII systems.

    - tye        

[reply]
[d/l]

      I don't see how "logical" is confusing if people understand that it means the object stands-in for something else. A lowercase "a" does not stand in for an uppercase "A", so I wouldn't call it a logical "A".

      The CGI.pm example just demostrates the hoops that Lincoln jumped through. Whether Mac Classic was right or wrong, it still was what it was. I didn't pick how these C libs were written or how these operating systems were designed. I'm not defending them. I just deal with it and get on with life.

      --
      brian d foy <bdfoy@cpan.org>
[reply]

In Section Seekers of Perl Wisdom