NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Env::Export
More |
Login
| Reply
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
I hope you're not serious (Score:1)
Hi Ovid
All you're doing is adding obfuscation to %ENV.
Big mistake.
Re: (Score:2)
Diagnosing $ENV{FEILD} is better? What's your solution?
Re:I hope you're not serious (Score:1)
Hash::Util's lock_keys seems like a good solution to me.
Reply to This
Parent
Re: (Score:2)
Except that sometimes people need to add environment variables. Boom!
Re: (Score:1)
Exactly right. At the very least, using PAR would be entirely out of the question. And you never know when someone down the road thinks *your* deployment strategy sucked big time and wants to do it over differently.
Re: (Score:1)
There is also an unlock_keys function for that case. And then if you're paranoid, you re-lock it. And if you want to use PAR later, you can have lock_keys be done conditionally depending on whether you are in your development environment or are all packaged up with PAR.
My experience is that using lock_keys to cause typos in hash accesses to blow up has a similar effect on catching my typos to strict. Albeit with a performance overhead. And the bonus is that it works for any kind of hash.
An example where