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})
<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?
Larry Leszczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
