perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [mp2 bug] Perl*Env issues
Date Thu, 16 Dec 2004 23:08:48 GMT

>>1) copy environ to %ENV and detach at the very beginning.
>>now if a vhost with its own interpreter changes %ENV it won't affect the
>>base server.
> Each vhost will be able to have its own <Perl> sections and/or
> PerlRequire, independent from the main server config, right?

Oops, this is a problem. No, only vhosts with their own perl interpreter 
can have a different %ENV.

In order to make those things independent per vhost,

Perl(Pass|Set)Env will affect only the right vhost/base, but any 
manipulation in the perl code will affect them all, since there is only 
one %ENV.

>>if you set $ENV{MYFOO} at startup it won't stay around, unless you
>>explicitly asked to post it forward. What I don't like about it is that
>>$ENV{PATH} is set in the perl code (e.g. startup), but needs to be
>>marked in httpd.conf, that's ugly.
> Yes, if you assume that setting something in %ENV at startup implies the
> equivalent of PerlPassEnv, you shouldn't need to explicitly do the
> PerlPassEnv for it.  I think 99% of the time I've touched %ENV in startup
> code, it was something that needed to be passed along, so it would be nice
> if that happened automatically.  If you needed something in %ENV at
> startup but did *not* want it passed along, either do it in a localized
> %ENV, or delete from %ENV after use in your startup code.

right, that's the idea

>>How about this solution:
> [... lots of steps ...]
>>How does that sound?
> Sounds good to me - I think you're basically getting at:
> - Startup code %ENV initially contains copy of original environ from shell
> - %ENV passed along to workers will contain only those keys that are:
>     1) Specified in PerlPassEnv or PerlSetEnv directives, or
>     2) Set/modified in unlocalized %ENV by startup code

That's correct.

In fact PerlPassEnv could be emulated from perl by:

  $ENV{FOO} = $ENV{FOO};

since it performs a set operation.

>>The only remaining problem that I see is PerlSetEnv, if there is a
>>PerlRequire'd file and PerlSetEnv, and both try to set/modify the same
>>entry, it's not the order in httpd.conf that will determine which is the
>>latest value, but the order of evalution of PerlRequire vs. PerlSetEnv.
>>Another thing to ensure is that PerlSetEnv is run before PerlRequire,
>>since it's possible that the file will want to refer to the ENV var set
>>by PerlSetEnv.
> I don't think that is a problem, if the precedence rule is made clear that
> all PerlSetEnv are always evaluated first regardless of position.  If it
> worked that way, you would still be able to have a PerlRequire or <Perl>
> section that relied on the setting of a PerlSetEnv, e.g. these would do
> the same thing:
>    PerlSetEnv  FOO 1
>    PerlRequire my::Module    (internally uses $ENV{FOO})
> or (less obvious)
>    PerlRequire my::Module    (internally uses $ENV{FOO})
>    PerlSetEnv  FOO 1
> What you would *not* be able to do is this:
>    PerlRequire my::Module    (internally sets $ENV{FOO})
>    PerlSetEnv  FOO 1         (to override the module setting)
> But that is ok because instead you could do:
>    PerlRequire my::Module    (internally sets $ENV{FOO})
>    <Perl>
>       $ENV{FOO} = 1;         (to override the module setting)
>    </Perl>
> It is sounding like the rules would be:
> 1) Evaluate all PerlSetEnv first, in order of occurrence
> 2) Evaluate all PerlRequire and <Perl> sections in main server config,
>    in order of occurrence
> 3) Evaluate all PerlRequire and <Perl> sections in each vhost, in order of
>    occurrence (each vhost could have a different %ENV at this point)
> 4) For each interpreter, clean up %ENV (according to delete list rules you
>    described) before passing to workers
> Is this what you mean?

As you have raised the problem of vhosts, this is probably not a way to 
go. I think what we could do is having PerlSetEnv and PerlPassEnv have no 
effect at startup phase at all, so if you need to manipulate any env vars 
at startup, you just do it from Perl. when you are done with all the 
manipulations in perl and the post_config phase is over, we can now apply
PerlSetEnv and PerlPassEnv, the former will override any settings done 
from Perl until this moment. And in which case things will work correctly 
across vhosts. i.e. you will be able to set two different values for the 
same key in two different hosts (but only for post_config phases). Is 
there a problem with this approach?

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message