in reply to Re^2: Help with RC4
in thread Help with RC4

Hmm, binmode should not be needed on Linux (or Unix.) From perldoc -f binmode: 

   Arranges for FILEHANDLE to be read or written in "binary" 
   or "text" mode on systems where the run-time libraries
   distinguish between binary and text files..

[download]
But the libraries on Unix-like systems make no such distinction. I'm guessing that the measures you took worked around the bug I mentioned below.

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

Replies are listed 'Best First'.
Re^4: Help with RC4
by PodMaster (Abbot) on Jul 26, 2004 at 06:19 UTC
    From `perldoc -f binmode', perl 5.8.4, emphasis mine
    On some systems (in general, DOS and Windows-based systems) binmode() is necessary when you're not working with a text file. For the sake of portability it is a good idea to always use it when appropriate, and to never use it when it isn't appropriate. Also, people can set their I/O to be by default UTF-8 encoded Unicode, not bytes.

    In other words: regardless of platform, use binmode() on binary data, like for example images.

    images, executables, zipfiles, tarballs, encrypted ...

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
      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
[reply]
        No, this is not a bug. perl-5.8.x has many improvements over perl-5.6.x, so if you're going to be using perl-5.8.x, you need to learn what those are.

        5.6 had only 2 IO disciplines: ":crlf" (the default) and ":raw" (binmode) and did not support unicode properly. 5.8 has support for other disciplines including utf8.

        `perldoc perl58delta' (emphasis mine)

        ...
        * 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). ...

        MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
        I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

In Section Seekers of Perl Wisdom