Hi Stas -
> I propose the following "simple" solution:
>
> 1) Keep %ENV intact at the server startup, so anything set in the shell is
> seen from perl
> 2) PerlPassEnv and PerlSetEnv aren't run yet but postponed to until after
> post_config.
> 3) just before starting workers, detach %ENV from environ, cleaning it up
> completely. now run PerlPassEnv and PerlSetEnv from (2)
>
> That way we don't have to deal with the painful timing of PerlPassEnv and
> PerlSetEnv. We simply document that those have an affect *only*
> post-post_config phase, i.e. starting from child_init phase. If someone
> wants to modify %ENV as it's seen from shell, they can just do that with
> <Perl> sections.
I like it a lot, it should be easy for people to understand the flow.
Just want to make sure I understand something: I think in #3 above when
you say "cleaning it up completely", you mean cleaning up environ
completely (so workers don't inherit) but keeping %ENV available for
PerlPassEnv, right? So I should be able to do something like this:
(assume shell env has PATH and INSTANCE variables set)
<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>
PerlPassEnv PATH
(now worker %ENV contains modified PATH, but not INSTANCE)
Yes?
Thanks,
Larry Leszczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
