Stas Bekman wrote:
Geoffrey Young wrote:
if you're seeing something different but following the same steps, then we clearly need some tests to flesh this out, though I'm not sure now how we would undo -T for a single set of tests in the suite.
Sorry, you are right, I was looking at the wrong printout. I did:
use Data::Dumper; warn Dumper [EMAIL PROTECTED]; warn Dumper $ENV{PERL5LIB};
So @INC didn't have it, but $ENV{PERL5LIB} had.
So it's only when PERL5LIB is set outside and PerlPassEnv is used it affects mod_perl.
actually, PerlPassEnv isn't required.
Though since everybody is better off running with -T, it doesn't make any difference. The question is whether we should support PERL5LIB despite -T or not.
>>> I don't see that in core. I see some special handling for tainting >>> in the test suite, though. but you could be right. >> >> which core? 1 or 2?
In mp1 tt does that regardless tainting:
yes, that I knew. it was the special treatment of -T that I didn't see.
in src/modules/perl/mod_perl.c:
/* SetEnv PERL5LIB */ if (!MP_INCPUSH(cld)) { char *path = (char *)table_get(r->subprocess_env, "PERL5LIB");
if (path) { perl_inc_unshift(path); MP_INCPUSH_on(cld); } }
right. and that was my point all along - (Perl)SetEnv doesn't work in 2.0. it did work in 1.0, but the syntax is funky since you can PerlSetEnv anywhere, even within a container, so sometimes it works and sometimes it doesn't, depending on when the one-per-request processing happens.
notice that it doesn't even split path on ':'.
yup :)
so I'm back to my original suggestion: let's mark (Perl)SetEnv PERL5LIB as deprecated, leave $ENV{PERL5LIB} behaving as perl does automatically (including ignoring under -T), and suggest PerlSwitches -I as the canonical way to add additional paths to @INC from httpd.conf.
--Geoff
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
