perl-dev mailing list archives

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

> In fact this will do exactly the same:
>     PerlPassEnv PATH
>     <Perl>
>        $ENV{PATH} = $ENV{INSTANCE} eq 'development'
>                     ? "$ENV{PATH}:/extra/devl/path/needed/by/my/modules"
>                     : "$ENV{PATH}:/extra/prod/path/needed/by/my/modules";
>     </Perl>

Yes, I was not trying to imply that order in httpd.conf mattered, only
order of evaluation.

> 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?

> 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.

> 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

> 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})
      $ENV{FOO} = 1;         (to override the module setting)

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?

Larry Leszczynski

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

View raw message