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

I'm trying to redirect STDOUT and STDERR to dev null in a mod_perl handler using the following code:

open(STDOUT, ">/dev/null") or $log->die("Unable to redirect STDOUT to dev null: $!"); open(STDERR, ">/dev/null") or $log->die("Unable to redirect STDERR to dev null: $!");

I'm obviously doing something boneheaded, because this gives me the following error:

[Mon Nov 27 16:54:52 2006] [error] [client 192.168.0.115] Can't locate object method "OPEN" via package "Apache::RequestRec" at ..

I'm confused .. I thought open was available everywhere .. you know, like a CORE function? I did a chdir a little before the open, and mod_perl didn't complain about that.

Thanks ..

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Replies are listed 'Best First'.
Re: mod_perl seems to have disappeared the open function
by rhesa (Vicar) on Nov 27, 2006 at 23:10 UTC
    I'm not a mod_perl internals expert to any degree, but it wouldn't surprise me at all if STDOUT and STDERR were actually tied variables to an Apache subclass. In which case, the error message might start to make a bit more sense.

    In fact, the docs say just that. See http://perl.apache.org/docs/1.0/guide/porting.html#STDIN__STDOUT_and_STDERR_streams for the nitty-gritty. That whole section might be interesting.

    BTW, I'm having a hard time parsing your node title. Are you sure things can disappear things in English?

      If so, I think that means the problem should be solved by using proper scoping.

      { local *STDOUT; local *STDERR; open(STDOUT, ">/dev/null") or $log->die("Unable to redirect STDOUT to dev null: $!"); open(STDERR, ">/dev/null") or $log->die("Unable to redirect STDERR to dev null: $!"); ... }

      Why are you redirecting to null (slow!) rather than just closing the file handle?

      { local *STDOUT; local *STDERR; ... }
          Why are you redirecting to null (slow!) rather than just closing the file handle?

        Huh. Good question. Well, to quote a movie I saw recently, "It's complicated" (I think that was MI:3).

        I actually want to run Ghostscript within mod_perl and pipe commands to it, but unfortunately Ghostscript is quite chatty, so to keep things clean, I want to disable the output streams. I'm also thinking it might be useful to re-direct the output streams to temporary files until I get all this stuff figured out.

        Alex / talexb / Toronto

        "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        I'm not a mod_perl internals expert to any degree, but it wouldn't surprise me at all if STDOUT and STDERR were actually tied variables to an Apache subclass. In which case, the error message might start to make a bit more sense.

      Of course, you are right. It has been too long since I programmed using mod_perl, and I've forgotten a lot. Thanks for the link to the Apache docs.

        BTW, I'm having a hard time parsing your node title. Are you sure things can disappear things in English?

      Sorry -- Saturday I had a show in Peterborough, abuot 90 minutes away, and I drove back to Toronto after the show, getting home at 2am. I ran around doing errands and cooking supper during the afternoon, then spent hours that night watching Tom Hanks in the DaVinci Code -- both the movie and all of the extras -- so had square eyeballs by the time I finally went to bed at 1am. Then I was paged at 415am because we had a Production problem that took me an hour to resolve and clean up after.

      So when I wrote this at the end of the day I wasn't making much sense. The title should probably be something like mod_perl seems to have caused open to disappear.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Re: mod_perl seems to have disappeared the open function
by Firefly258 (Beadle) on Nov 27, 2006 at 23:27 UTC
    In mod_perl a lot of perl's CORE functionality is overridden to get mod_perl scripts to exhibit a different behaviour in the Apache environment, to enable persistence across subsequent invokations, faster execution times, etc.

    Perl Specifics in the mod_perl Environment from the practical mod_perl book explains why it is necessary to sometimes use CORE functions to override functions defined in the mod_perl/Apache modules.

    I'm not sure why open() isn't CORE::open() in your case as it shouln't be the case. Maybe it helps to explicitly call the intended function.
    CORE::open STDOUT, '>', '/dev/null' or ...


    perl -e '$,=$",$_=(split/\W/,$^X)[y[eval]]]+--$_],print+just,another,split,hack'er
Re: mod_perl seems to have disappeared the open function (untie)
by tye (Sage) on Nov 27, 2006 at 23:51 UTC

    Since STDOUT and/or STDERR is clearly tied to Apache::RequestRec, you should probably close then untie them first. I don't have this problem in my mod_perl environment so I can't test a specific solution suggestion. Something like:

    close STDOUT; untie *STDOUT; open( STDOUT, ...

    - tye