STDIN is not used with mod_perl.
It depends on how you write your program. When you don't qualify your read and print calls with $r, then you do use STDIN, though mod_perl overrides it, and does the qualified $r->read() calls behind the scenes (via the perlio layer), but essentially mod_cgi and mod_perl do exactly the same thing at the end. If you turn the binmode inside your script, I think it should work just fine, since the perlio layer subclasses PerlIOBase_binmode, which is supposed to do the right thing.
Yes, I was just talking about his example, which uses CGI.pm, which in turn gets its input from $r->args and $r->read under mod_perl, so binmode(STDIN) won't help.
Boris (CC'ed) has started a similar discussion on the modperl dev list, which is now redirected to the apreq list (the home of Apache::Request), Boris is going to post the details on how to make Apache::Request handle unicode/utf8 transparently for the users. I can't see the post yet, but it should happen soon. subscribe to the [EMAIL PROTECTED] if you want to take part in that discussion.
I've seen the discussion, but I'm not really interested in UTF-8 support for either APR::Table or Apache::Request, since I don't put my own strings in APR tables and I use param wrapper functions anyway. Calling utf8::decode() for a few parameters is no big deal. I'm more interested in the UTF-8 support that's hopefully coming with DBI 1.44, since rewriting hundreds of strings in hashes fetched via DBI would be much more of a performance issue.
-- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
