Skip Menu |
 

This queue is for tickets about the Env-Sanctify CPAN distribution.

Report information
The Basics
Id: 46929
Status: resolved
Worked: 10 min
Priority: 0/
Queue: Env-Sanctify

People
Owner: Nobody in particular
Requestors: frequency [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Problem When Re-Defining Env::Sanctify Object
Download (untitled) / with headers
text/plain 2.2k
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...
Updated documentation. Many thanks.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.