Maybe there's no need to change what happens when the cache is being loaded. Instead,
in the code to retrieve the value of an element of %ENV, move the check for the
special case of $ENV{DEFAULT} early enough so that in that case, the cache is never
even consulted; and don't worry about the trivial consumption of resources in loading
one more element, that we know will never be used; I think simplicity would trump
efficiency at that point. Just a thought ...
> -----Original Message-----
> From: Craig Berry [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 02, 2003 6:06 PM
> To: Tom Edelson
> Cc: [EMAIL PROTECTED]
> Subject: Re: how to un-special-ize $ENV{DEFAULT}
>
>
>
> On Tuesday, December 02, 2003, at 09:34AM, Tom Edelson
> <[EMAIL PROTECTED]> wrote:
>
> >Regarding this statement from PERLDOC PERLVMS:
> >
> > The element "$ENV{DEFAULT}" is special: when read,
> it returns
> > Perl's current default device and directory, and
> when set, it
> > resets them, regardless of the definition of
> PERL_ENV_TABLES. It
> > cannot be cleared or deleted; attempts to do so are silently
> > ignored.
> >
> >In 5.6.1, at least, it looks like the act of evaluating "keys(%ENV)"
> >makes this no longer true:
>
> I can confirm this in a recent development patchlevel as
> well. It looks like the keys function causes the invocation
> of prime_env_iter() in vms.c, which spawns a process to do
> SHOW LOGICAL * and parses through the output. It provides no
> special treatment for the 'DEFAULT' key the way the other
> environment lookup functions do (those that deal with an
> individual key), so it loads the equivalence name as the hash value.
>
> It's not immediately clear to me whether we should simply
> skip loading DEFAULT at this step or if we should load the
> value of the current working directory. I'm concerned that
> if we do the latter, that value may be cached and will not
> get updated if the directory changes. As a workaround, you
> can simply do delete($ENV{DEFAULT}) to get back the special behavior.
>
