Ah. That would do it. As it happens I'm using CGI::Simple but I noticed that CGI.pm has the same effect, which is why I wrote the OP that way. So now I just need to dig in and figure out what to do about it. My issue is that I'm only using the form-parsing aspects, not the HTML-generation aspects, and the data I'm writing to STDOUT has nothing to do with the CGI per se (it's actually more like log data), so I need to find a way around that behavior.

If you're curious about what my actual program is doing it is something like this.

Not sure if you've already worked around the problem but one apparent way is to just revert the settings with some binmode calls of your own (after CGI has been loaded):

use CGI;
binmode $_, ':crlf' for (\*STDOUT, \*STDERR, \*STDIN);

print "foo\nbar\n";
[download]

That produced the right "0D0A" line endings for me.

yes. and only for $OS=~/^(WINDOWS|DOS|OS2|MSWin|CYGWIN)/;

From the CGI docs:

PRETTY-PRINTING HTML

By default, all the HTML produced by these functions comes out as one long line without carriage returns or indentation. This is yuck, but it does reduce the size of the documents by 10-20%. To get pretty-printed output, please use the CGI::Pretty manpage, a subclass contributed by Brian Paulsen.

use CGI::Pretty;
print "foo\n";
print "bar\n";
[download]

Does what you mean.

I should have mentioned this isn't actually a CGI script. I need CGI.pm (or really CGI::Simple but same deal) for other purposes. When I run my program STDOUT is actually redirected to a file.

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.