3 ms·

There is no bug with `\r\n`. I checked the provided example, fixed `\N` to be `\n` (this bug causes a compilation error, so it would be noticed during compilati

There is no bug with `\r\n`. I checked the provided example, fixed `\N` to be `\n` (this bug causes a compilation error, so it would be noticed during compilation). The hex output is as follows. 00000000: 436f 6e74 656e 742d 5479 7065 3a20 7465 Content-Type: te 00000010: 7874 2f70 6c61 696e 3b20 6368 6172 7365 xt/plain; charse 00000020: 743d 4953 4f2d 3838 3539 2d31 0d0a 0d0a t=ISO-8859-1.... 00000030: 5041 5241 4d3a 0a PARAM:. Note the 0d0a0d0a sequence following the character set. This is `\r\n\r\n`, as it should be.

user5994461 7y ago
This was running on Linux? That's odd. The bug works on Python. Wondering how Perl does the formatting to end up with \r\n. Either way, still puzzling there is a typo in the official example.
- lazyjones 7y ago
  You can find similar examples with just \n in the official Apache docs on CGI: https://httpd.apache.org/docs/2.4/howto/cgi.html https://httpd.apache.org/docs/2.4/howto/cgi.html The solution for this puzzle is that mod_cgi will simply convert LF to CRLF silently. (more precisely: it parses the headers the script outputs in a relaxed way and lets the server write them in a correct format later)
- GlitchMr 7y ago
  This is directly executed (without HTTP server involved, yes, it's possible to run CGI programs directly in shell) program on Linux.
adrianmonk 7y ago
In Perl, "\n" has a similar kind of platform-specific behavior like it does in some other languages (such as C). Its output is more or less defined as "whatever is appropriate on this type of machine". It's useful for printing for the console or writing to a text file that will be used on the local machine, but not for everything. If you're building a message to go on the wire as part of a protocol that needs certain specific characters, and if you're trying to write portable code, then you shouldn't use "\n" (or "\r"). This is actually covered in the "perldoc perlop" documentation under the "Quote and Quote-like Operators" section (available at https://perldoc.perl.org/perlop.html#Quote-Like-Operators https://perldoc.perl.org/perlop.html#Quote-Like-Operators): > 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 the ancient Macs (pre-MacOS X) of yesteryear, these used to be reversed, and on systems without a line terminator, printing "\n" might 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. So, arguably it is a bug to write it that way, but not exactly a fault of the language since it is providing a facility to do something useful and also explicitly warning you against using it for something else. One way to think of "\n" is that it's similar to localized strings. In both cases, you have a need to let the system render something differently depending on context (platform or user location/language/etc., respectively). It's helpful to have that abstracted away, but you should realize that magic is happening and that you generally shouldn't use it for machine-to-machine communication.

user5994461 7y ago

This was running on Linux? That's odd. The bug works on Python. Wondering how Perl does the formatting to end up with \r\n. Either way, still puzzling there is a typo in the official example.

lazyjones 7y ago
You can find similar examples with just \n in the official Apache docs on CGI: https://httpd.apache.org/docs/2.4/howto/cgi.html https://httpd.apache.org/docs/2.4/howto/cgi.html The solution for this puzzle is that mod_cgi will simply convert LF to CRLF silently. (more precisely: it parses the headers the script outputs in a relaxed way and lets the server write them in a correct format later)
GlitchMr 7y ago
This is directly executed (without HTTP server involved, yes, it's possible to run CGI programs directly in shell) program on Linux.

adrianmonk 7y ago

In Perl, "\n" has a similar kind of platform-specific behavior like it does in some other languages (such as C). Its output is more or less defined as "whatever is appropriate on this type of machine". It's useful for printing for the console or writing to a text file that will be used on the local machine, but not for everything. If you're building a message to go on the wire as part of a protocol that needs certain specific characters, and if you're trying to write portable code, then you shouldn't use "\n" (or "\r"). This is actually covered in the "perldoc perlop" documentation under the "Quote and Quote-like Operators" section (available at https://perldoc.perl.org/perlop.html#Quote-Like-Operators https://perldoc.perl.org/perlop.html#Quote-Like-Operators): > 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 the ancient Macs (pre-MacOS X) of yesteryear, these used to be reversed, and on systems without a line terminator, printing "\n" might 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. So, arguably it is a bug to write it that way, but not exactly a fault of the language since it is providing a facility to do something useful and also explicitly warning you against using it for something else. One way to think of "\n" is that it's similar to localized strings. In both cases, you have a need to let the system render something differently depending on context (platform or user location/language/etc., respectively). It's helpful to have that abstracted away, but you should realize that magic is happening and that you generally shouldn't use it for machine-to-machine communication.