hmm... i think i have a similar question.

i want to prevent people from writing data directly to the
apache connection and instead force them to use an object i
provide for generating output. they can call $obj->print()
directly, but i also want them to be able to use 'print
"foo\n"' as is standard in handlers and registry scripts.

seems like i want to untie STDIN and STDOUT as per below..
but then how do i attach those handles to my object's print
method? is tieing the correct approach, or is there some
other kind of filehandle magic i can use?

On Fri, 13 Jul 2001, Jonathan Bartlett wrote:

> I know this has been discussed a little before, but the Test.pm
> PerlHandler I've attached does not work as expected.  The reason being
> that dup-ing a read filehandle to STDIN overwrote STDOUT instead (well,
> actually both, since apache apparently uses the same handle for
> input and output).  Anyway, this actually worked in RH 6.x, but stopped
> working when I installed 7.1.  My guess is that for whatever versions are
> in 6.x STDIN and STDOUT were only tied for registry scripts, but in 7.x
> they got tied for regular content handlers as well.
>
> Currently, I'm working around it by putting
>
> untie(*STDIN);
> untie(*STDOUT);
>
> at the beginning of my handler.  Is that the best way to go?  I tried
> sticking it in the initialization part of the module, but that didn't
> work.  Why is that?
>
> Anyway, if anyone has additional questions about what I'm doing here, let
> me know.  The example is quite contrived, but it does affect a real-world
> situation.
>
> The actual problem line is open(STDIN, "<&RD"), which dups RD onto
> filehandle 1 (STDOUT) instead of 0 (STDIN).  Later, when '/bin/ls' is
> exec-d, when it tries to write to STDOUT, it gets EBADF because there's a
> read file handle there.
>
> Anyway, the script can be installed with
>
> PerlRequire Test.pm
> <location /mytest/>
> SetHandler perl-script
> PerlHandler WRI::Test::handler
> </location>
>
> Anyway, let me know if there is a better way of handling the situation.
>
> Jon
>
>

Reply via email to