again, that's not required and it doesn't work now anyway - if it's in %ENV it doesn't need to be passed to take effect. at least that's what my tests show.
That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
How about the following compromise: we make a special case for 'PerlPassEnv PERL5LIB' if -T is in effect? It works correctly without -T, so we only want to circumvent -T here, as a special case.
Actually I'm interested to know why PERl5LIB is ignored on -T, may be the reason is critical enough that we should just respect that perl's feature and leave it alone?
that's my feeling. if the only reason to support PERL5LIB is so that users who are already familiar with the syntax can specify their own libraries in a way that's familiar (since there are other ways to do it with mod_perl, after all), then I see no reason not to follow perl's lead here.
if we make a special case, then we're essentially circumventing the protection that perl ordinarily guarantees with -T, which could result in unforseen consequences. taint mode exists as a protection, so it's probably unwise to work around it just because we can.
OK, I'm convinced on this one. We should add a new entry to porting/compat.pod then, including you summary above. Should I do that, or will you handle that.
I still want to know why PERL5LIB is ignored by perl, I will ask p5p as perlsec.pod doesn't say anything about it.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
