Well, yeah, but that's for the sake of portability with OSen that do make the distinction between text and binary. Unix (and Linux) make no such distinction. Also, his data is good 'ol 7-bit ASCII. Why should he have difficulty reading that regardless of binmode? And why should setting LANG to 'C' address the problem? (I've tested it. It does.)

It's a bug. It's either a Perl bug in 5.8.0 or a bug in Red Hat's implementation on RHEL3. They have stepped up to fix this in U3. I've tested the patch that fixes the problem.

"Even if you are on the right track, you'll get run over if you just sit there." - Will Rogers

... * If your environment variables (LC_ALL, LC_CTYPE, LANG) look like you
want to use UTF-8 (any of the the variables match "/utf-?8/i"), your
STDIN, STDOUT, STDERR handles and the default open layer (see open)
are marked as UTF-8. (This feature, like other new features that
combine Unicode and I/O, work only if you are using PerlIO, but
that's the default.)

Note that after this Perl really does assume that everything is
UTF-8: for example if some input handle is not, Perl will probably
very soon complain about the input data like this "Malformed UTF-8
..." since any old eight-bit data is not legal UTF-8.

Note for code authors: if you want to enable your users to use UTF-8
as their default encoding but in your code still have eight-bit I/O
streams (such as images or zip files), you need to explicitly open()
or binmode() with ":bytes" (see "open" in perlfunc and "binmode" in
perlfunc), or you can just use "binmode(FH)" (nice for pre-5.8.0
backward compatibility).
...

MJDsays "you can't just make shit up and expect the computer to know what you mean, retardo!"

Went to join the gridlock to see it
Held an eclipse party
Watched a live feed
I cn"t see tge kwubosd to amswr thus
I tried to see it, but 8000 miles of rock got in the way
What eclipse?
Wanted to see it, but they wouldn't reschedule it
Read the book instead