perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pratik <pratikn...@gmail.com>
Subject Re: [mp2 bug] Perl*Env issues
Date Sun, 19 Dec 2004 06:29:33 GMT
I believe that if effect is not in sync with the order of occurrence,
it can create confusions. Probably, one possible solution ( and
probably the simplest one ) is to populate %ENV before any
<Perl>..</Perl> block.

I'd be interested in writing the patch for this if required. But it
will be really great to have this issue sorted out. Becaue without it,
we will not be able to upgrade to mp2 :(

Thanks,
Pratik

On Thu, 16 Dec 2004 18:08:48 -0500, Stas Bekman <stas@stason.org> wrote:
> 
> >>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
> http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message