Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> Grr, it actually doesn't do that at all. Where did you see it doing
>>> that?
>>
>>
>>
>> whoops...
>>
>> I was trying to write subenv.t tests yesterday for the patch I
>> proposed and
>> saw that behavior. but now I can't reproduce it. so, false alarm,
>> and many
>> appologies. and whew, I'm glad I'm wrong - one less thing to argue about
>> changing ;)
>
>
> ;)
>
> I was only suggesting that as a possible idea. Anyway, now the test
> tests that it does the right thing(tm).
bah, I knew I wasn't dreaming: it's there in env.t
my $env = $r->subprocess_env;
...
$ENV{FOO} = 2;
ok $ENV{FOO} == 2;
ok $env->get('FOO') == 2;
so, I suppose it's only with perl-script or +SetupEnv (or some combination
of them).
as I said before, I'm surprised by this - in mp1 they weren't tied, so we've
added a feature.
it seems to me that not only is this a lot of overhead, but I don't see the
need to tie them together if we move SetupEnv logic to the actual
perl-script/modperl handler and document that SetupEnv is really for
populating %ENV for mod_cgi-like emulation (which was always my
understanding anyway).
do you remember why they were tied in the first place?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
