You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/02/04 21:54:04 UTC
new %ENV population behavior
hi all
ok, I think the below patch handles everything that we had talked about over
the past week wrt +SetupEnv and %ENV.
in essence, here is the behavior that this patch implements:
- under normal +SetupEnv circumstances (default perl-script or
modperl+SetupEnv), %ENV is set up with CGI variables and subprocess_env
table entries just prior to content generation.
- -SetupEnv (default modperl or perl-script-SetupEnv) does nothing at all
to %ENV.
- $r->subprocess_env() in a void context will force early population of
%ENV with both CGI variables and subprocess_env table entries
- regardless of the state of %ENV, +SetupEnv _always_ tries to populate
%ENV with subprocess_env table entries. this prevents void
$r->subprocess_env() calls from essentially locking out future table entries
from making it to %ENV.
- CGI variables are set up only once for efficiency - either just prior to
content generation or on the first $r->subprocess_env() void call.
- void $r->subprocess_env() calls will _not_ assure that future
subprocess_env entries will make it to %ENV - that's for +SetupEnv.
the net result is that with +SetupEnv content handlers are assured to have
both CGI variables and all subprocess_env table entries without interference
from handlers in prior phases. the contents of %ENV is not guaranteed
anywhere else. specifically it is not guaranteed to be consistent across
phases (but it never was anyway).
anyway, the test setup for this is interesting - I wanted to use t_cmp from
within the handlers, which required a bit of non-standard juggling. as for
the per-connection interpreter scope, it's not required for the tests to
pass under normal circumstances, but I was occasionally getting "plan before
you test!" errors that would go away with no changes, which I attributed to
swapped interpreters. I suppose that I could plan at the start of each
request, but that might be even more strange.
--Geoff
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> So +1, next it'd be nice to refactor that select/unselect into macros,
> which will make the code more readable.
ok, I'll work on that a bit and see what I can come up with. stay tuned...
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: new %ENV population behavior
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
>>Now, given that the select code is run anyway inside the callback, just
>>take the select/unselect parts out of if (MpDirSETUP_ENV(dcfg)), similar
>>to perl-script.
>
>
> I don't see where parts are removed for perl-script versus what I had. but
> I think I see how the MpInterpPUTBACK stuff can be removed in the modperl
> handler, since you only need context for the call to
> modperl_env_request_populate and the callback does another full
> select/rcfg->interp population later. is that what you meant?
The callback doesn't do a full select AFAIR, if you already did a select. But
your patch below is fine. I was just suggesting to have if
(MpDirSETUP_ENV(dcfg)) only around modperl_env_request_populate.
So +1, next it'd be nice to refactor that select/unselect into macros, which
will make the code more readable.
>>With the fix above, yes. I haven't read through the rest of the patch,
>>assuming that it's the same as the previous one.
>
>
> it was different in that it incorporated your other comments (which is why I
> posted the whole thing :)
ah, of course, I've scanned the parts I've commented on and it looks good.
nice work, Geoff!
__________________________________________________________________
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
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> That's the problem with your latest patch. You should not unselect the
> interp before you finish the callback. Nested calls to select are NOOPs
> (i.e. they figure out that the interpreter was already selected and
> won't do it again), same goes for unselect. So you need to move that
> unselect untill after _run:
ok, that makes sense. (duh).
> Now, given that the select code is run anyway inside the callback, just
> take the select/unselect parts out of if (MpDirSETUP_ENV(dcfg)), similar
> to perl-script.
I don't see where parts are removed for perl-script versus what I had. but
I think I see how the MpInterpPUTBACK stuff can be removed in the modperl
handler, since you only need context for the call to
modperl_env_request_populate and the callback does another full
select/rcfg->interp population later. is that what you meant?
> With the fix above, yes. I haven't read through the rest of the patch,
> assuming that it's the same as the previous one.
it was different in that it incorporated your other comments (which is why I
posted the whole thing :)
--Geoff
Re: new %ENV population behavior
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>I'd just like to see that refactored so there is no duplication between
>>perl-script and modperl handlers. Perhaps use some macros.
>
>
> ok, I incorporated your suggestions - here is a new patch.
>
> the only thing I didn't really see was how to refactor the modperl and
> perl-script handlers any more than they already are. I mean, sure, we can
> shuffle stuff around, but each approach I can think of exchanges (very)
> little duplication for other things. for instance, I could move the call to
> modperl_env_request_popualte to modperl_response_handler_run, but it would
> mean that (worst case) perl-script would have 3 calls to the interpreter
> selection logic instead of (worst case) two.
That's the problem with your latest patch. You should not unselect the interp
before you finish the callback. Nested calls to select are NOOPs (i.e. they
figure out that the interpreter was already selected and won't do it again),
same goes for unselect. So you need to move that unselect untill after _run:
> + /* default is -SetupEnv, add if PerlOption +SetupEnv */
> + if (MpDirSETUP_ENV(dcfg)) {
> + MP_dRCFG;
>
> +#ifdef USE_ITHREADS
> + if (MpInterpPUTBACK(interp)) {
> + /* PerlInterpScope handler */
> + modperl_interp_unselect(interp);
> + rcfg->interp = NULL;
> + }
> +#endif
> +
> }
Otherwise it's indeed wasteful.
Now, given that the select code is run anyway inside the callback, just take
the select/unselect parts out of if (MpDirSETUP_ENV(dcfg)), similar to
perl-script.
[...]
>
>>But this can
>>(and probably should) be done after you commit your current work.
>
>
> yeah, I think that's what I'd like to do. so, save any gaping holes in the
> current patch (such as forgetting to return the interpreter to the pool :)
> I'd like to just go forward with it. then, we have a series of tests
> checked in an a functionality we know is working, so someone can refactor
> without fear of breaking anything.
>
> sound ok?
With the fix above, yes. I haven't read through the rest of the patch,
assuming that it's the same as the previous one.
If you post a new patch for mod_perl.c, please post only it.
__________________________________________________________________
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
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> I'd just like to see that refactored so there is no duplication between
> perl-script and modperl handlers. Perhaps use some macros.
ok, I incorporated your suggestions - here is a new patch.
the only thing I didn't really see was how to refactor the modperl and
perl-script handlers any more than they already are. I mean, sure, we can
shuffle stuff around, but each approach I can think of exchanges (very)
little duplication for other things. for instance, I could move the call to
modperl_env_request_popualte to modperl_response_handler_run, but it would
mean that (worst case) perl-script would have 3 calls to the interpreter
selection logic instead of (worst case) two. or I could move the
MpDirSETUP_ENV(dcfg) logic inside modperl_env_request_populate but then the
logic in subprocess_env needs to be more complex, saving and restoring the
SETUP_ENV setting on each call.
maybe modperl_env_configure_request_dir and
modperl_env_configure_request_srv could be combined, too...
> But this can
> (and probably should) be done after you commit your current work.
yeah, I think that's what I'd like to do. so, save any gaping holes in the
current patch (such as forgetting to return the interpreter to the pool :)
I'd like to just go forward with it. then, we have a series of tests
checked in an a functionality we know is working, so someone can refactor
without fear of breaking anything.
sound ok?
--Geoff
Re: new %ENV population behavior
Posted by Stas Bekman <st...@stason.org>.
>>also why modperl and perl-script have a duplication of the env handling,
>>shouldn't it use the same code (probably moving into the _run handler).
>
>
> well, it's not an exact duplicate - perl-script defaults to +SetupEnv, while
> modperl does not, which means that the if-logic is slightly different. so,
> the code duplication is really this in perl-script
>
> if (MpDirSETUP_ENV(dcfg) || !MpDirSeenSETUP_ENV(dcfg)) {
> modperl_env_request_populate(aTHX_ r);
> }
>
> versus this in modperl
>
> if (MpDirSETUP_ENV(dcfg)) {
>
> modperl_env_request_populate(aTHX_ r);
> }
yeah, but that can be arranged so that you don't duplicate it
in perl-script
if (!MpDirSeenSETUP_ENV(dcfg)) {
MpDirSETUP_ENV_On(dcfg);
}
and inside the common function:
if (MpDirSETUP_ENV(dcfg)) {
modperl_env_request_populate(aTHX_ r);
}
or does it make things less clear to the reader?
> plus the new interpreter selection in the modperl handler.
which is (should be) exactly the same as in 'perl-script', no?
>>But why did you introduce the interp select code? it's not bare bones
>>handler any longer. can we get away w/o it?
>
>
> I needed the interpreter to get a THX so I can populate the environment
> +SetupEnv. and it is still bare bones unless +SetupEnv is called - see the
>
> /* default is -SetupEnv, add if PerlOption +SetupEnv */
> if (MpDirSETUP_ENV(dcfg)) {
>
> that hold this (and the below) logic. see also the very end of this email
>
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107540306610034&w=2
I can't find any references to select/unselect interp code in that mail. But
sure, you need aTHX, no questions. I thought it was adding an overhead to the
'modperl' handler, but it was calling the select inside modperl_callback
anyway. So there is no problem.
I'd just like to see that refactored so there is no duplication between
perl-script and modperl handlers. Perhaps use some macros. But this can (and
probably should) be done after you commit your current work.
>>>+ modperl_env_request_populate(aTHX_ r);
>>
>>Are you sure? 'modperl' doesn't do anything to %ENV unless +SetupEnv is on.
>
>
> that's exactly it. see the above note.
Ah, sorry, I've missed the closing brace because of the #ifdef/#endif. That's
perfect.
>>>-# PerlOptions +SetupEnv is needed here, because we want the mod_cgi
>>>-# env to be set at the access phase. without it, perl-script sets it
>>>-# only for the response phase
>>>-PerlOptions +SetupEnv
>>>+PerlOptions -SetupEnv
>>
>>
>>why not using 'SetHandler modperl', instead of 'perl-script/-SetupEnv'?
>
>
> I just toggled the bit to minimize the changes.
sure, let's keep it this way, so it's sort of a test on its own.
>>In any case the comments in t/modperl/cookie.t are wrong with your .pm
>>patch, because you have added -SetupEnv. I'm talking about:
>>
>>
>>> # in this test we should be able get the cookie via %ENV,
>>> # since 'SetHandler perl-script' sets up mod_cgi env var...
>
>
> the rest of the comment is
>
> ...Moreover
> # adding 'PerlOptions +SetupEnv' adds them at the very first stage used
> # by mod_perl handlers,
>
> which is no longer true - what we had agreed on was making %ENV only
> relevant during the response phase. that's why the +SetupEnv logic is in
> the modperl handler and not elsewhere.
>
> anyway, that's the problem I was trying to fix, and I was trying to do it in
> the simplest way possible. once the other changes are in place, if you have
> better suggestions for fixing cookie.t I'm open to them.
I wasn't talking about the code, but the comment. Again with your change it says:
# in this test we should be able get the cookie via %ENV,
# since 'SetHandler perl-script' sets up mod_cgi env var. Moreover
# calling $r->subprocess_env adds them on demand. the last sub-test makes
# sure, that mod_cgi env vars don't persist and are properly re-set at
# the end of each request
but the test (after your changes) doesn't do that, because you have set
-SetupEnv. So 'SetHandler perl-script' is irrelevant (that's why I've
suggested to replace perl-script/-SetupEnv with 'modperl'. So if the setup
remains as is, I think this is a more clear description:
# 'SetHandler perl-script' combined with 'PerlOptions +SetupEnv', or
# 'SetHandler modperl' don't populate %ENV with CGI vars. So in this test
# we call $r->subprocess_env, which does that on demand, and we are able
# to get the cookie via %ENV.
#
# The last sub-test makes sure, that mod_cgi env vars don't persist and
# are properly re-set at the end of each request
>>Also in modperl_env.c you had:
>>
>>+ MP_dRCFG;
>>+ MP_dSCFG(r->server);
>>...
>>+ /* only once per-request */
>>+ if (MpReqPERL_SET_ENV_SRV(rcfg)) {
>>+ return;
>>+ }
>>
>>sounds wasteful to me. It was outside the call originally. For some
>>reason you've moved it in:
>>
>>- /* only happens once per-request */
>>- if (MpDirSETUP_ENV(dcfg)) {
>>- modperl_env_request_populate(aTHX_ r);
>>- }
>>+ /* per-server PerlSetEnv and PerlPassEnv - only once
>>per-request */
>>+ modperl_env_configure_request_srv(aTHX_ r);
>>+
>>
>>same for modperl_env_configure_request_rec... oh may be I've got a bit
>>lost...
>
>
> my thought was that I preferred the cleaner approach in modperl_callback,
> allowing all of the ENV logic to be self-contained, rather than having
> modperl_callback make decisions on its own.
Since you call these only from one place, it's probably not as bad and will
give a significant speedup (as your current code goes, it'll dive into these
functions on almost every callback. It's much faster to make a binary compare
than calling a function, setup a few variables, and leave it.
> anyway, thanks for reviewing it :)
;)
__________________________________________________________________
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
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Great work, Geoff. But too big to swallow at once, may be will absorb it
> with time, but your descriptions sounds reasonable to me.
yes, it's a lot to take in. it took me a while to do it, too :)
>> +#ifdef USE_ITHREADS
>> + interp = modperl_interp_select(r, r->connection, r->server);
>> + aTHX = interp->perl;
>> + if (MpInterpPUTBACK(interp)) {
>> + rcfg->interp = interp;
>> + }
>> +#endif
>
>
> What about modperl_interp_unselect? See modperl_response_handler_cgi.
whoops :)
>
> also why modperl and perl-script have a duplication of the env handling,
> shouldn't it use the same code (probably moving into the _run handler).
well, it's not an exact duplicate - perl-script defaults to +SetupEnv, while
modperl does not, which means that the if-logic is slightly different. so,
the code duplication is really this in perl-script
if (MpDirSETUP_ENV(dcfg) || !MpDirSeenSETUP_ENV(dcfg)) {
modperl_env_request_populate(aTHX_ r);
}
versus this in modperl
if (MpDirSETUP_ENV(dcfg)) {
modperl_env_request_populate(aTHX_ r);
}
plus the new interpreter selection in the modperl handler.
>
> But why did you introduce the interp select code? it's not bare bones
> handler any longer. can we get away w/o it?
I needed the interpreter to get a THX so I can populate the environment
+SetupEnv. and it is still bare bones unless +SetupEnv is called - see the
/* default is -SetupEnv, add if PerlOption +SetupEnv */
if (MpDirSETUP_ENV(dcfg)) {
that hold this (and the below) logic. see also the very end of this email
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107540306610034&w=2
>
>> + modperl_env_request_populate(aTHX_ r);
>
> Are you sure? 'modperl' doesn't do anything to %ENV unless +SetupEnv is on.
that's exactly it. see the above note.
>> -# PerlOptions +SetupEnv is needed here, because we want the mod_cgi
>> -# env to be set at the access phase. without it, perl-script sets it
>> -# only for the response phase
>> -PerlOptions +SetupEnv
>> +PerlOptions -SetupEnv
>
>
> why not using 'SetHandler modperl', instead of 'perl-script/-SetupEnv'?
I just toggled the bit to minimize the changes.
>
> In any case the comments in t/modperl/cookie.t are wrong with your .pm
> patch, because you have added -SetupEnv. I'm talking about:
>
>> # in this test we should be able get the cookie via %ENV,
>> # since 'SetHandler perl-script' sets up mod_cgi env var...
the rest of the comment is
...Moreover
# adding 'PerlOptions +SetupEnv' adds them at the very first stage used
# by mod_perl handlers,
which is no longer true - what we had agreed on was making %ENV only
relevant during the response phase. that's why the +SetupEnv logic is in
the modperl handler and not elsewhere.
anyway, that's the problem I was trying to fix, and I was trying to do it in
the simplest way possible. once the other changes are in place, if you have
better suggestions for fixing cookie.t I'm open to them.
>
> Also in modperl_env.c you had:
>
> + MP_dRCFG;
> + MP_dSCFG(r->server);
> ...
> + /* only once per-request */
> + if (MpReqPERL_SET_ENV_SRV(rcfg)) {
> + return;
> + }
>
> sounds wasteful to me. It was outside the call originally. For some
> reason you've moved it in:
>
> - /* only happens once per-request */
> - if (MpDirSETUP_ENV(dcfg)) {
> - modperl_env_request_populate(aTHX_ r);
> - }
> + /* per-server PerlSetEnv and PerlPassEnv - only once
> per-request */
> + modperl_env_configure_request_srv(aTHX_ r);
> +
>
> same for modperl_env_configure_request_rec... oh may be I've got a bit
> lost...
my thought was that I preferred the cleaner approach in modperl_callback,
allowing all of the ENV logic to be self-contained, rather than having
modperl_callback make decisions on its own.
anyway, thanks for reviewing it :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: new %ENV population behavior
Posted by Stas Bekman <st...@stason.org>.
Great work, Geoff. But too big to swallow at once, may be will absorb it with
time, but your descriptions sounds reasonable to me. I think you'd like to
adjust/extend the docs while it's hot in your head ;)
I've just a few comments below:
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/mod_perl.c,v
> retrieving revision 1.206
> diff -u -r1.206 mod_perl.c
> --- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
> +++ src/modules/perl/mod_perl.c 6 Feb 2004 18:04:26 -0000
> @@ -837,8 +837,30 @@
>
> int modperl_response_handler(request_rec *r)
> {
> + MP_dDCFG;
> +
> +#ifdef USE_ITHREADS
> + pTHX;
> + modperl_interp_t *interp;
> +#endif
> +
> if (!strEQ(r->handler, "modperl")) {
> return DECLINED;
> + }
> +
> + /* default is -SetupEnv, add if PerlOption +SetupEnv */
> + if (MpDirSETUP_ENV(dcfg)) {
> + MP_dRCFG;
> +
> +#ifdef USE_ITHREADS
> + interp = modperl_interp_select(r, r->connection, r->server);
> + aTHX = interp->perl;
> + if (MpInterpPUTBACK(interp)) {
> + rcfg->interp = interp;
> + }
> +#endif
What about modperl_interp_unselect? See modperl_response_handler_cgi.
also why modperl and perl-script have a duplication of the env handling,
shouldn't it use the same code (probably moving into the _run handler).
But why did you introduce the interp select code? it's not bare bones handler
any longer. can we get away w/o it?
> + modperl_env_request_populate(aTHX_ r);
Are you sure? 'modperl' doesn't do anything to %ENV unless +SetupEnv is on.
> Index: t/modperl/cookie.t
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/t/modperl/cookie.t,v
> retrieving revision 1.2
> diff -u -r1.2 cookie.t
> --- t/modperl/cookie.t 22 Nov 2003 07:38:48 -0000 1.2
> +++ t/modperl/cookie.t 6 Feb 2004 18:04:28 -0000
> @@ -6,8 +6,7 @@
> #
> # in this test we should be able get the cookie via %ENV,
> # since 'SetHandler perl-script' sets up mod_cgi env var. Moreover
> -# adding 'PerlOptions +SetupEnv' adds them at the very first stage used
> -# by mod_perl handlers, 'access' in this test. the last sub-test makes
> +# calling $r->subprocess_env adds them on demand. the last sub-test makes
> # sure, that mod_cgi env vars don't persist and are properly re-set at
> # the end of each request
> #
> Index: t/response/TestModperl/cookie.pm
> ===================================================================
> RCS file: /home/cvspublic/modperl-2.0/t/response/TestModperl/cookie.pm,v
> retrieving revision 1.1
> diff -u -r1.1 cookie.pm
> --- t/response/TestModperl/cookie.pm 22 Sep 2003 23:34:45 -0000 1.1
> +++ t/response/TestModperl/cookie.pm 6 Feb 2004 18:04:28 -0000
> @@ -13,6 +13,9 @@
> sub access {
> my $r = shift;
>
> + # setup CGI variables early
> + $r->subprocess_env() if $r->args eq 'env';
> +
> my($key, $val) = cookie($r);
> my $cookie_is_expected =
> ($r->args eq 'header' or $r->args eq 'env') ? 1 : 0;
> @@ -48,7 +51,4 @@
> PerlInitHandler Apache::TestHandler::same_interp_fixup
> PerlAccessHandler TestModperl::cookie::access
> PerlResponseHandler TestModperl::cookie
> -# PerlOptions +SetupEnv is needed here, because we want the mod_cgi
> -# env to be set at the access phase. without it, perl-script sets it
> -# only for the response phase
> -PerlOptions +SetupEnv
> +PerlOptions -SetupEnv
why not using 'SetHandler modperl', instead of 'perl-script/-SetupEnv'?
In any case the comments in t/modperl/cookie.t are wrong with your .pm patch,
because you have added -SetupEnv. I'm talking about:
> # in this test we should be able get the cookie via %ENV,
> # since 'SetHandler perl-script' sets up mod_cgi env var...
Also in modperl_env.c you had:
+ MP_dRCFG;
+ MP_dSCFG(r->server);
...
+ /* only once per-request */
+ if (MpReqPERL_SET_ENV_SRV(rcfg)) {
+ return;
+ }
sounds wasteful to me. It was outside the call originally. For some reason
you've moved it in:
- /* only happens once per-request */
- if (MpDirSETUP_ENV(dcfg)) {
- modperl_env_request_populate(aTHX_ r);
- }
+ /* per-server PerlSetEnv and PerlPassEnv - only once per-request */
+ modperl_env_configure_request_srv(aTHX_ r);
+
same for modperl_env_configure_request_rec... oh may be I've got a bit lost...
__________________________________________________________________
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
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
>
> Geoffrey Young wrote:
>
>>hi all
>>
>>ok, I think the below patch handles everything that we had talked about over
>>the past week wrt +SetupEnv and %ENV.
>
>
> actually, there is a problem with PerlSetEnv, which is supposed to populate
> %ENV with only that variable as soon as possible. I can't remember the
> interaction between PerlSetEnv and PerlSetupEnv in mp1, but it seems like
> PerlSetEnv should happen regardless of the SetupEnv setting - it's a
> specific call to populate %ENV with a specific variable, rather than "oh, if
> people care about %ENV give them this too." at least that's my read on it.
ok, the attached patch addresses this. PerlSetEnv and PerlPassEnv always
are passed to %ENV, regardless of +SetupEnv.
other than that, the patch behaves the same way I described it initally.
--Geoff
Re: new %ENV population behavior
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
> hi all
>
> ok, I think the below patch handles everything that we had talked about over
> the past week wrt +SetupEnv and %ENV.
actually, there is a problem with PerlSetEnv, which is supposed to populate
%ENV with only that variable as soon as possible. I can't remember the
interaction between PerlSetEnv and PerlSetupEnv in mp1, but it seems like
PerlSetEnv should happen regardless of the SetupEnv setting - it's a
specific call to populate %ENV with a specific variable, rather than "oh, if
people care about %ENV give them this too." at least that's my read on it.
so, I still need to work up the patch a bit, but comments on the other
aspects of +SetupEnv welcome (as well as the above PerlSetEnv stuff).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org