Jan Dubois wrote on 2008-12-08:
> On Mon, 08 Dec 2008, Scott Stanton wrote:
>> This is a basic perl-5.8.8 distribution. ActivePerl has the same
>> issue, but it checks two different locations (HKLM\Software\Perl and
>> HKLM\Software\ActivePerl).
>
> I don't think it uses HKLM\Software\ActivePerl for anything at
runtime;
> it is just the installer that puts some stuff there.
>
> *All* Perl versions for Windows, going back to at least 5.005 will
fall
> back to the registry for environment variables starting with "PERL".
>
> If you run `perl -eprint$ENV{PERLFOO}` it will first check for an
> environment variable called PERLFOO, but if it isn't found, it will
> check first HKCU\Software\Perl and then HKLM\Software\Perl for a
> PERLFOO entry and return that. Only when none of them are set will
> you get undef.
>
> This is quiet annoying for embedding Perl into other applications
> since you have to check for a bunch of variables like PERL5OPT and
> even things like PERL_ENCODING etc as well.
>
> I'm not aware of a way to turn this "feature" off; the only thing
> you can do is set all these variables to benign default values before
> you call perl_perl_parse().
>
I just stumbled across this while looking back through old emails.
I wasn't aware of this "feature", and when I tried it myself it didn't
work.
It turns out that there is a way to turn it off for environment
variables accessed via %ENV: build your perl without PERL_IMPLICIT_SYS
(which is how mine is built, hence my initial confusion).
In win32.h, DYNAMIC_ENV_FETCH is only #defined if PERL_IMPLICIT_SYS is
#defined. When DYNAMIC_ENV_FETCH is #defined, hv_common() does a dynamic
lookup in the environment using PerlEnv_ENVgetenv_len(), which winds up
in win32_getenv(), which looks up PERL* variables in HKCU or HKLM if
they weren't in the environment. But without DYNAMIC_ENV_FETCH,
hv_common() only looks in the %ENV hash that it already has.
However, all the special PERL* environment variables used by perl's own
C code (e.g. PERL5LIB, PERL5OPT, PERL_UNICODE, PERL_HASH_SEED, etc) seem
to be accessed by calls to PerlEnv_getenv(), which does still go through
win32_getenv(), so they are looked up the registry even when
PERL_IMPLICIT_SYS is not defined.
Seems nasty to me: without PERL_IMPLICIT_SYS, anything calling getenv()
will check the registry too, but anything using %ENV won't! So if you
set PERL5LIB in the registry then perl.c sees it when it calls
PerlEnv_getenv("PERL5LIB") but the perl script you're running won't see
it when it looks for $ENV{PERL5LIB}!
