| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
adds a "process" watchdog method that forces use of a separate
process for the watchdog "watcher".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This logic in sv_magic is wrong:
if (SvREADONLY(sv)) {
if (
/* its okay to attach magic to shared strings; the subsequent
* upgrade to PVMG will unshare the string */
!(SvFAKE(sv) && SvTYPE(sv) < SVt_PVMG)
&& IN_PERL_RUNTIME
&& !PERL_MAGIC_TYPE_READONLY_ACCEPTABLE(how)
)
{
Perl_croak_no_modify(aTHX);
}
}
There is nothing wrong with attaching magic to a shared string that
will stay shared. Also, shared strings are not always < SVt_PVMG.
Sometimes a PVMG or PVLV can end up with a shared string. In those
cases, the logic above treats them as read-only, which they ain’t.
The easiest example is a downgraded typeglob:
$x = *foo; # now a PVGV
undef $x ; # downgraded to PVMG
$x = __PACKAGE__; # now a shared string (COW)
tie $x, "main"; # bang! $x is considered read-only
sub main::TIESCALAR{bless[]}
|
|
|
|
|
|
|
|
|
|
| |
The code in gv.c for loading a tie module automatically
(S_require_tie_mod) was only loading the module if its stash did not
exist or if a particular method (usually TIEHASH) could not be found.
But it was triggering autoloading, such that a universal AUTOLOAD
method would allow it to ‘find’ the method it was looking for, even if
it did not exist. So autovivifying the package somehow (e.g., by men-
tioning one of its symbols) could prevent the module from loading.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This type of thing isn’t officially supported, but perl shouldn’t be
freeing unallocated memory (the 9th octet of a freed HEK) as a result:
$::{whatever} = __PACKAGE__;
*{"whatever"};
A string stored in the symbol table like that is actually a subroutine
stub. ‘sub foo($)’ is stored as '$' in the "foo" slot to save space.
gv_init_pvn (formerly known as gv_init) checks SvPOK first thing,
assuming, if it is set, that it can reuse SvPVX as the CV’s prototype,
without reallocating or copying it. That works most of the time.
For COW strings (such as those returned by __PACKAGE__), SvPVX points
to the hek_key field (the 9th octet) of a shared HEK. When the CV is
freed, it ends up trying to do Safefree(that_hek + 8) effectively,
which is bad.
|
|
|
|
|
|
|
|
| |
If goto &sub triggers a destructor that undefines &sub, a
crash ensues.
This commit adds an extra check in pp_goto after the unwinding of the
previous sub’s scope.
|
|
|
|
|
| |
Now tied() returns the actual scalar used to hold the tie object,
so one can write weaken(tied $foo).
|
|
|
|
|
| |
Well, I at least ran test_porting after making that ‘only doc’ change!
But then I committed with -a by mistake. Oh well.
|
|
|
|
| |
Copied almost verbatim from text supplied by Kevin Ryde.
|
|
|
|
|
| |
This was added to avoid the warning from $[, but these two test
scripts no longer mention $[.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This program:
#!perl -l
sub myprint { print @_ }
print substr *foo, 1;
myprint substr *foo, 1;
produces:
main::foo
Can't coerce GLOB to string in substr at - line 4.
Ouch!
I would expect \substr simply to give me a scalar that peeks into the
original string, but without modifying the original until the return
value of \substr is actually assigned to.
But it turns out that it coerces the original into a string immedi-
ately, unless it’s GMAGICAL. I find the exception for magical varia-
ble rather befuddling. I can only imagine it was for efficency (since
the stringified form will be overwritten when magic_setsubstr calls
SvGETMAGIC), but that doesn’t make sense as the original variable can
itself be modified between the return of the special lvalue and the
assignment to that lvalue.
Since magic_setsubstr itself coerces the variable into a string upon
assignment to the lvalue, we can just remove the coercion code from
pp_substr.
But that causes double uninitialized warnings in cases like
substr($undef, 0,0) = "lrep".
That happens because pp_substr is still stringifying the variable (but
without modifying it). It has to do that, as it looks at the length
of the original string and accordingly adjusts the offsets stored in
the lvalue if they are negative or if they extend beyond the end of
the string.
So this commit takes the simple route of avoiding the warning in
pp_substr by only stringifying a variable that is SvOK if called in
lvalue context.
Hence, assignment to substr($tied...) will continue to call FETCH
twice, but that is not a new bug.
The ideal solution would be for the offsets to be translated in mg.c,
rather than in pp_substr. But that would be a more involved change
(including most of this commit, which is therefore not wasted) with
potential backward-compatibility issue with negative numbers.
A side effect it that the ‘Attempt to use reference as lvalue in
substr’ warning now occurs during the assignment to the substr lvalue,
rather that substr itself. This means it occurs even for tied varia-
bles, so things are now more consistent.
The example at the beginning could still croak if the glob were
replaced with a null string, so this commit only partially allevi-
ates the pain.
|
|
|
|
|
|
|
|
|
|
|
| |
A slight mistake in the evalbytes.t test script caused a lot of tests
not be testing what they were supposed to be testing for. I used
'qq(\x...)' instead of qq('\x...'). (I.e., I was trying to embed lit-
eral Unicode characters in the string, rather than pass escapes to
evalbytes.)
I had wondered at the time why it worked without my doing anything, so
I probably should have looked deeper.
|
| |
|
| |
|
|
|
|
|
|
| |
sysread uses SvPV_force, which has a bug in it. Even if the SV_GMAGIC
flag is passed to sv_pvn_force_flags (which SvPV_force does), it
ignores magic in any typeglob argument.
|
|
|
|
|
|
|
| |
Not only does this commit make four-argument select call fetch once
on each argument (instead of sometimes 0 times), but it also checks
whether the argument is a string after calling fetch now, instead of
before, in determining whether to warn about a non-string.
|
|
|
|
|
| |
Commit a4499558 moved them under t/re along with the subst tests, but
these are unrelated to regexps.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was treating it as a version object and then failing the validation
test, instead of treating it as an invalid version format, as it does
with "versions":
$ ./perl -Ilib -e'$VERSION = "versions"; main->VERSION(1)'
Invalid version format (dotted-decimal versions require at least three parts) at -e line 1.
$ ./perl -Ilib -e'$VERSION = "version"; main->VERSION(1)'
Invalid version object at -e line 1.
See also perl #102586.
|
|
|
|
| |
See perl #102586.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
After much alternation, altercation and alteration, __SUB__ is
finally here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also restores the subroutine redefinition warning for newly-cre-
ated XSUBs outside the autouse package. See below.
This commit added the exemption to fix a known bug, that loading a
module and importing from it would cause a redefinition warning if
there were an autouse stub:
perl-5.004_03-1092-g2f34f9d
commit 2f34f9d4825ac9262ece854fc4c50479f4838ff8
Author: Ilya Zakharevich <ilya@math.berkeley.edu>
Date: Mon Mar 2 16:36:02 1998 -0500
Make autouse -w-safe
p4raw-id: //depot/perl@781
The subroutine redefinition warning occurs in three places.
This commit removed the autouse exemption from two
of them. I can’t see how it wasn’t a mistake, as <5104D4DBC598D211B5FE0000F8FE7EB202D49EE9@mbtlipnt02.btlabs.bt.co.uk>
(the apparent source of the patch, makes no mention of it:
perl-5.005_02-2920-ge476b1b
commit e476b1b5c29f354cf8dad61a9fc6d855bdfb5b7d
Author: Gurusamy Sarathy <gsar@cpan.org>
Date: Sun Feb 20 22:58:09 2000 +0000
lexical warnings update, ability to inspect bitmask in calling
scope, among other things (from Paul Marquess)
p4raw-id: //depot/perl@5170
This commit refactored things to remove some compiler warnings, but
in doing so reversed the logic of the condition, causing redefini-
tion warnings for newly-created XSUBs to apply only to subs from the
autouse package:
perl-5.8.0-5131-g66a1b24
commit 66a1b24beb76ea873ad4caa57ee3ab9df945afbf
Author: Andy Lester <andy@petdance.com>
Date: Mon Jun 6 05:11:07 2005 -0500
Random cleanups #47
Message-ID: <20050606151107.GC7022@petdance.com>
p4raw-id: //depot/perl@24735
I’ve basically reinstated the changes in 2f34f9d4, but with tests
this time.
It may not make sense for autouse to be exempt for newATTRSUB and
newXS, but keeping the logic surrounding the warning as close as
possible to being the same could allow future refactorings to
merge them.
|
|
|
|
|
|
| |
When an optimised constant is promoted to a CV, the name’s length can
be passed straight to newCONSTSUB_flags, as it now has a length param-
eter which it passes to newXS_len_flags.
|
|
|
|
|
|
|
|
|
| |
Those require() calls are compiled as BASEOPs, so it is invalid to look for
their op_first member when they are translated to a call to the global
override subroutine. The new entersub call should get $_ in its argument
list instead.
This fixes [perl #78260].
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sort $f @list accepts a globref for $f, and probably has since Perl
5.000, even if it was by mistake that it ever worked.
It doesn’t respect get-magic, however:
$ perl -le 'sub s { $b <=> $a }; $f = \*s; print sort $f 1,2,3'
321
$ ./perl -Ilib -le '
sub TIESCALAR{bless[]}
sub FETCH {*s}
sub s { $b <=> $a };
tie $f, "";
$g = \$f;
print sort $g 1,2,3'
Not a subroutine reference at -e line 1.
Interestingly, this commit added support for sort $coderef @foo:
commit 7a4920e67d1e2d67a4397a908141c6608866ebb0
Author: Graham Barr <gbarr@pobox.com>
Date: Fri Nov 27 05:16:50 1998 +0000
integrate change#2246 from mainline, while still allowing
C<sort $globref @foo>
allow C<sort $coderef @foo>
p4raw-link: @2246 on //depot/perl: c6e96bcb406bc8b8d8610606459ff606ad6883aa
p4raw-id: //depot/maint-5.005/perl@2315
p4raw-integrated: from //depot/perl@2314 'merge in' t/op/sort.t
(@1760..)
If I’m reading this code correctly, it did so by nulling out whatever
op used to come after the pushmark (now it is always a null):
$ perl -MO=Concise -e 'sort $fo @fo'8 <@> leave[1 ref] vKP/REFC ->(end)
1 <0> enter ->2
2 <;> nextstate(main 1 -e:1) v:{ ->3
7 <@> sort vKS ->8
3 <0> pushmark s ->4
- <1> null K/1 ->5 <--- Lo!
- <1> ex-rv2sv sK/1 ->-
4 <#> gvsv[*fo] s ->5
6 <1> rv2av[t3] lK/1 ->7
5 <#> gv[*fo] s ->6
-e syntax OK
To preserve the globref support (which the nulled op was providing
before), it added it to sv_2cv, which was the wrong place if you ask
me. Now it means that &{\*_} works, in addition to &{*_}. Other
deref ops don’t have this property. Bug? Maybe. But we can just
pretend it’s a feature and live with it.
In any case, extracting the entry of a typeglob without calling get-
magic on it first doesn’t seem right.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When open() has three arguments and the second ends with & the third
argument is treated as a handle.
In some cases get-magic was being skipped; in others, it was being
called three times.
This commit fixes it by modifying sv_2io.
In 5.8.x (before commit 7a5fd60d4), sv_2io did not call get-magic at
all except when croaking ("Bad filehandle: %"SVf). In 5.10.0 (after
commit 7a5fd60d4), it started calling get-magic only if the sv was
neither a glob, a reference, or undef. So it has never been reliable
in its invocation of get-magic.
sv_2io now consistently skips get-magic on the sv passed in directly
to it (open(), the only caller in the core, has already called get-
magic before passing it in). It now calls get-magic on SvRV(sv) if
what is passed in is a reference, so open(fh, ">&", \$tied) will work.
Interestingly, open supports multiple levels of references:
\\\\\\\\\\\\open+f,">&",\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\*STDOUT;print{f}"Just another Perl hacker,\n",.\\\\\\\y\\\
|
|
|
|
|
| |
The magic-copying is skipped for GVs. This logic goes back to perl
5.000 (patch a0d0e21e). I think it has always been wrong.
|
|
|
|
| |
This was something e1dccc0d3 removed that b82b06b8 failed to restore.
|
|
|
|
|
|
|
|
|
|
| |
Change every existing instance of isa_ok() to use object_ok(). This is safe because
before this point, t/test.pl's isa_ok() only worked on objects. lib/dbmt_common.pl is
the last hold out because it uses Test::More.
These are like isa_ok() but they also check if it's a class or an object.
This lets the core tests defend against outlandish bugs while allowing
t/test.pl to retain feature parity with Test::More.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It doesn’t any more.
Now the hints are localised in a separate inner scope surrounding the
call to yyparse. This meant moving hint-handling code from pp_require
and pp_entereval into S_doeval.
Some tests in t/comp/hints.t were testing for the buggy behaviour, so
they have been adjusted.
Basically, this fixes
sub import {
eval "strict->import"
}
which should work the same way as
sub import {
strict->import
}
but was not working because %^H and $^H were being localised to
the eval at its run time, not just its compilation. So the values
assigned to %^H and $^H at the eval’s run time would simply be lost.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is scary:
#use sort 'stable';
require re; re->import('/x');
eval '
print "a b" =~ /a b/ ? "ok\n" : "nokay\n";
use re "/m";
print "a b" =~ /a b/ ? "ok\n" : "nokay\n";
';
It prints:
ok
nokay
The re->import statement is supposed to apply to the caller that
is currently being compiled, but it makes ‘use re "/m"’ enable
/x as well.
Uncomment the ‘use sort’ line, and you get:
ok
ok
which is even scarier.
eval"" is supposed to compile its argument with the hints under which
the eval itself was compiled.
Whenever %^H is modified, a flag (HINT_LOCALIZE_HH; LHH hereinafter)
is set in $^H.
When eval is called, it checks the LHH flag in the hints from the time
it was compiled, to determine whether to reset %^H. If LHH is set,
it creates a new %^H based on the hints under which it was compiled.
Otherwise, it just leaves %^H alone.
The problem is that %^H and LHH may be set some time later
(re->import), so when the eval runs there is junk in %^H that
does not apply to the contents of the eval.
There are two layers at which the hints hash is stored. There is the
Perl-level hash, %^H, and then there is a faster cop-hints-hash struc-
ture underneath. It’s the latter that is actually used during compi-
lation. %^H is just a Perl front-end to it.
When eval does not reset %^H and %^H has junk in it, the two get
out of sync, because eval always sets the cop-hints-hash correctly.
Hence the first print in the first example above compiles without
‘use re "/x"’. The ‘use re’ statement after it modifies the %^H-with-
junk-in-it, which then gets synchronised with the cop-hints-hash,
turning on /x for the next print statement.
Adding ‘use sort’ to the top of the program makes the problem go
away, because, since sort.pm uses %^H, LHH is set when eval() itself
is compiled.
This commit fixes this by having pp_entereval check not only the LHH
flag from the hints under which it was compiled, but also the hints of
the currently compiling code ($^H / PL_hints).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gv_efullname4 produces undef if the GV points to no stash, instead of
using __ANON__, as it does when the stash has no name.
Instead of going through hoops to try and work around it elsewhere, fix
gv_efullname4.
This means that
$x = *$io;
$x .= "whate’er";
no longer produces an uninitialized warning. (The warning was rather
strange, as defined() returned true.)
This commit also gives the glob the name $__ANONIO__ (yes, with a dol-
lar sign). It may seem a little strange, but there is precedent in
other autovivified globs, such as those open() produces when it cannot
determine the variable name (e.g, open $t->{fh}).
|
|
|
|
|
|
|
|
|
|
|
| |
This function evaluates its argument as a byte string, regardless of
the internal encoding. It croaks if the string contains characters
outside the byte range. Hence evalbytes(" use utf8; '\xc4\x80' ")
will return "\x{100}", even if the original string had the UTF8 flag
on, and evalbytes(" '\xc4\x80' ") will return "\xc4\x80".
This has the side effect of fixing the deparsing of CORE::break under
‘use feature’ when there is an override.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 900ac0519e (5.11.0) sped up keys() on an empty hash by modify-
ing the iteration code not to loop through the buckets looking for an
entry if the number of keys is 0. Interestingly, it had no visible
affect on keys(), but it *did* have one on each(). Resetting the ite-
rator’s current bucket number (RITER) used to be done inside that loop
in hv_iternext. keys() always begins by resetting the iterator, so it
was unaffected. But each %empty will leave the iterator as-is. It
will be set on an empty hash if the last element was deleted while an
iterator was active. This has buggy side-effects.
$h{1} = 2;
each %h; # returns (1, 2)
delete $h{1};
each %h; # returns false; should reset iterator
$h{1}=2;
print each %h, "\n"; # prints nothing
Commit 3b37eb248 (5.15.0), which changed the way S_hfreeentries works.
(S_hfreentries is called by all operators that empty hashes, such as
%h=() and undef %h.) Now S_hfreentries does nothing if the hash is
empty. That change on its own should have been harmless, but the
result was that even %h=() won’t reset RITER after each() has put
things in an inconsistent state. This caused test failures in
Text::Tabulate.
So the solution, of course, is to complete the change made by
900ac0519e and reset the iterator properly in hv_iternext if the
hash is empty.
|
| |
|
|
|
|
|
|
|
| |
If, during scope exit, a pad var is being cleared for reuse, it needs
to be hidden from magic methods that might reference it through weak
references. Otherwise they can end up modifying the var that will be
seen next time that scope is entered, by blessing it, etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a lexical variable goes out of scope, as in
{
my %lexical_variable;
...
}
# no longer in scope here
it is supposed to disappear as far as Perl code can tell. That the
same SV is reused the next time that scope is entered is an implement-
ation detail.
The move of hashes’ back-references from magic into the HvAUX struc-
ture in 5.10 caused this implementation detail to leak through.
Normally, weak references to pad variables going out of scope are
killed off:
{
my $scalar;
weaken ($global_scalar = \$scalar);
}
# here $global_scalar is undef
When hashes’ back-references were moved, leave_scope was not updated
to account. (For non-hash variables, it’s the mg_free call that takes
care of it.) So in this case:
{
my %hash;
weaken ($global_scalar = \%hash);
}
$global_scalar would still reference a hash, but one marked PADSTALE.
Modifications to that hash through the reference would be visible the
next time the scope was entered.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was causing some interesting HTML::Element failures, which were
only triggered by HTML::DOM’s test suite.
ref’s TARG can become tainted if another op in the same statement
turns on tainting for the rest of the statement, so it becomes a PVMG.
The next call to the same ref will try to sv_upgrade it to a PV (which
is lower). Only the macro version, SvUPGRADE, checks whether the
upgrade is needed.
ref only calls sv_sethek when it has a blessed object for its argu-
ment, hence the strange-looking test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit makes CORE::glob bypassing glob overrides.
A side effect of the fix is that, with the default glob implementa-
tion, undefining *CORE::GLOBAL::glob no longer results in an ‘unde-
fined subroutine’ error.
Another side effect is that compilation of a glob op no longer assumes
that the loading of File::Glob will create the *CORE::GLOB::glob type-
glob. ‘++$INC{"File/Glob.pm"}; sub File::Glob::csh_glob; eval '<*>';’
used to crash.
This is accomplished using a mechanism similar to lock() and
threads::shared. There is a new PL_globhook interpreter varia-
ble that pp_glob calls when there is no override present. Thus,
File::Glob (which is supposed to be transparent, as it *is* the
built-in implementation) no longer interferes with the user mechanism
for overriding glob.
This removes one tier from the five or so hacks that constitute glob’s
implementation, and which work together to make it one of the buggiest
and most inconsistent areas of Perl.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit rewrites File::Glob::csh_glob (which implements perl’s
default globbing behaviour) in C.
This fixes a problem introduced by 0b0e6d70f. If there is an
unmatched quotation mark, all attempts to parse the pattern are
discarded and it is treated as a single token. Prior to 0b0e6d70f,
whitespace was stripped from both ends in that case. As of 0b0e6d70f,
it was only stripped from the beginning. This commit restores the
pre-0b0e6d70f behaviour with unmatched quotes. It doesn’t take
'a"b\ ' into account (where the space is escaped), but that wasn’t
handled properly before 0b0e6d70f, either.
This also finishes making csh_glob consistent with regard to quota-
tion marks. Commit 0b0e6d70f attempted to do that, but did not strip
out medial quotation marks, as in a"b"c. Text::ParseWords does not
provide an interface for stripping out quotation marks but leaving
backslashes, which I tried to work around, not fully understanding
the implications. Anyway, this new C implementation doesn’t use
Text::ParseWords.
The latter fix caused a test failure, but that test was there to make
sure the behaviour didn’t change depending on whether File::Glob
was loaded before the first mention of glob(). (In 5.6, loading
File::Glob first would make perl revert to external csh glob, ironic-
ally enough.) This commit modifies the test to test for sameness,
rather than exact output. In fact, this change causes perl and
miniperl to be consistent, and probably also causes glob to be more
consistent across platforms (think of VMS).
Another effect of the translation to C is that the Unicode Bug is
fixed with regard to splitting patterns. The C code effectively does
/\s/a now (which I believe is the only sane behaviour in this case),
instead of treating the string differently depending on the UTF8 flag.
The Unicode Bug is still present with regard to actual globbing.
This commit introduces one regression. This code:
undef %File::Glob::;
glob("nometachars");
will no longer return anything, because csh_glob no longer holds a
reference count on the $File::Glob::DEFAULT_FLAGS glob. Any code that
does that is beyond crazy.
The big advantage to this patch is speed. Something like
‘@files = <*>’ is 18% faster in a folder of 300 files. For smaller
folders there should be an even more notable difference.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit a3342be368 localised %ENV before calling csh for glob. But
that causes <~> to stop working. So this commit clears out %ENV
*except* for $ENV{HOME}.
It relies on the way magic works: Before localising the %ENV hash, it
retrieves its $ENV{HOME} element, which is a magical scalar. It calls
get-magic to store the value in the scalar itself, localises %ENV, and
then calls set-magic on the element, to signal (deceitfully) that an assignment has just happened. So the cached value in the magical sca-
lar is used and assigned to the env var.
|