On Wed, Feb 10, 2010 at 02:12:24AM +0100, Jakub Narebski wrote:
> On Tue, 9 Feb 2010 at 11:30 +0100, Jakub Narebski wrote:
>
> > The cache_fetch subroutine captures output (from STDOUT only, as
> > STDERR is usually logged) using either ->push_layer()/->pop_layer()
> > from PerlIO::Util submodule (if it is available), or by setting and
> > restoring *STDOUT. Note that only the former could be tested reliably
> > to be reliable in t9503 test!
>
> Scratch that, I have just checked that (at least for Apache + mod_cgi,
> but I don't think that it matters) the latter solution, with setting
> and restoring *STDOUT doesn't work: I would get data in cache (so it
> can be restored later), but instead of output I would get Internal Server
> Error ("The server encountered an internal error or misconfiguration and
> was unable to complete your request.") without even a hint what the
> problem was. Sprinkling "die ...: $!" didn't help to catch this error:
> I suspect that the problem is with capturing.
>
> So we either would have to live with non-core PerlIO::Util or (pure Perl)
> Capture::Tiny, or do the 'print -> print $out' patch...
All the magic methods seem to be troublesome, but in that case I'd
really prefer a level of indirection instead of filehandle - as is,
'print (...) -> output (...)' ins. of 'print (...) -> print $out (...)'
(or whatever). That should be really flexible and completely
futureproof, and I don't think the level of indirection would incur any
measurable overhead, would it?
--
Petr "Pasky" Baudis
If you can't see the value in jet powered ants you should turn in
your nerd card. -- Dunbal (464142)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html