cazz has asked for the wisdom of the Perl Monks concerning the following question:

I was in the mist of working on code that prints binary data when I noticed my perl installation acting wonky. On my laptop, perl acts as expected: 
$ perl -e 'print "\xff"' | od -x
0000000 00ff
0000001

[download]
On my dev box, perl now does this: 
$ perl -e 'print "\xff"' |od -x
0000000 bfc3
0000002

[download]
What changed? And of course, more importantly, how do I put it back? I've straced perl, and it is printing the wrong thing: 
$ strace perl -e 'print "\xff"' 2>&1| grep write
write(1, "\303\277", 2ÿ)                 = 2

[download]
BTW, this is 5.8.0, installed from Redhat's perl-5.8.0-55 RPM.

Replies are listed 'Best First'.
Re: perl gone wonkers when handling binary data?
by RMGir (Prior) on Apr 14, 2004 at 16:17 UTC
    Try this: 
    LANG=en_US strace perl -e 'print "\xff"' 2>&1| grep write

    [download]
    There's a known issue with RH9 and its perl 5.8.0 build; the default LANG setting (en_US.utf8) results in perl running in UTF-8 mode rather than ASCII mode.

    The LANG setting sould set things to rights.

    (Edit: ysth++ is correct, it's not strictly an RH9 issue. But RH9 does set the default LANG value as utf8, which exposes the perl 5.8.0 issue)


    Mike
[reply]
[d/l]
      It's a little misleading to say "its [RedHat's] perl 5.8.0 build". The fault was with perl5.8.0 in general, which by design assumed STDOUT would expect utf8 if in a utf8 locale. Redhat just was unfortunate in being one of the most prominent platforms to hit the combination of 5.8.0 and the OS defaulting to have a utf8 locale.

      This design was reconsidered in 5.8.1. See perl581delta for more information (including about the new -C switch to explicitly state what STDIN, etc. expect.)

[reply]
      yep, that was it. thanks.
[reply]

Back to Seekers of Perl Wisdom