in reply to Re: strange newline behavior in Win32 with CGI.pm and STDOUT
in thread strange newline behavior in Win32 with CGI.pm and STDOUT

Yes, but see perlport where it says:
Perl uses \n to represent the "logical" newline, where what is logical may depend on the platform in use. In MacPerl, \n always means \015 . In DOSish perls, \n usually means \012 , but when accessing a file in "text" mode, STDIO translates it to (or from) \015\012 , depending on whether you're reading or writing
or perlop where it 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 sys- tems read "\r" as ASCII CR and "\n" as ASCII LF. For example, on a Mac, these are reversed, and on systems without line terminator, print- ing "\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.
My point is, this should work as is, and it does if I don't use CGI.
  • Comment on Re^2: strange newline behavior in Win32 with CGI.pm and STDOUT