| Subject: | Problem When Re-Defining Env::Sanctify Object |
This is really just a [suggested] documentation patch, because I don't
think there's anything you can really do about this, but...
If you first create an Env::Sanctify object, and then replace it with
another one, the new environment variables set are overridden by the
"replacement" from Env::Sanctify.
Using this test case:
#!/usr/bin/perl
use warnings;
use strict;
use Env::Sanctify;
$ENV{TEST} = 'Test thing';
my $sanctify = Env::Sanctify->sanctify( sanctify => [ 'TEST' ] );
printf "My ENV{TEST}: %s\n", $ENV{TEST};
$sanctify = Env::Sanctify->sanctify( env => { TEST => 'Other answer' } );
printf "My ENV{TEST}: %s\n", $ENV{TEST};
This script outputs:
My ENV{TEST}:
My ENV{TEST}: Test thing
(Ignoring the warning because ENV{TEST} wasn't initialized for the first
printf, which is the expected behaviour)
Now that I really think about it, I see the error of my ways: when the
second Env::Sanctify object is created, the first one doesn't go out of
scope until the new one is created. That is, when I am constructing the
second object, the right side is clearly evaluated first (makes sense)
before being assigned to $sanctify, thus making the first object's
refcount drop to zero.
The workaround for this is to undefine the first object, thus forcing a
cleanup, before replacing it with the second newly constructed object.
Makes sense.
I'm not sure if this is something that can (or should) be fixed in your
code -- I don't think your code is broken, just the way I happened to be
using it -- but something in the documentation noting this sort of thing
would be nice.
On the other hand, you could see when restoring the old environment if
the variable has changed from under Env::Sanctify. That is, let's say
you want to remove PATH:
my $sanctify = Env::Sanctify->sanctify(sanctify => ['PATH']);
# But then you set it too
$ENV{PATH} = "blah";
Then $sanctify going out of scope should not doing anything with PATH,
since it was changed out from under it.
On the other hand, that doesn't make sense at all, and somewhat defeats
the purpose of Env::Sanctify (in case someone wants it to do something
akin to using local, where the old value is restored when $sanctify
falls out of scope).
So really, just something to warn users: if you're redefining $sanctify,
then you'll run into trouble...