Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • The closest I can find is the "Env" module, which ties environment variables to scalars or arrays, for sugary purposes.

    Let me know if you don't think you'll get around to this, and I'll be glad to throw something up on GitHub :-).



    • Feel free to do this. It's great if I just think of ideas and others implement them :) Curiously, as you can see from replies below, some folks don't like this idea.

  • Hi Ovid

    All you're doing is adding obfuscation to %ENV.

    Big mistake.

    • Diagnosing $ENV{FEILD} is better? What's your solution?

      • Hash::Util's lock_keys seems like a good solution to me.

        • Except that sometimes people need to add environment variables. Boom!

          • 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.

          • 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

      • If not Hash::Util, then perhaps Internals could be put to use: []

  • Here's a simple implementation. (I think Env::Constant is a better name than Env::Export) You can find it with some basic tests and docs at []. Contact Adam Kennedy if you want commit access to that repository*.

    package Env::Constant;

    use 5.006001;
    use strict;
    use warnings;
    use Carp qw/croak/;

    our $VERSION = '0.01';

    sub import {
        my $class = shift;
        my $matching_keys = shift;
        $matching_keys = eval {qr/$matching_keys/}

    • I certainly won't give you grief for Subversion. If it's good enough for you, that's fine. It's when people tell other people that "my solution should be your solution" that it's worth asking if that solution is optimal.

      • Oh, my comment wasn't targetted at you specifically. What you're saying is exactly my point of view. I even think that perl moving to git was one of the best things to happen to it in the past years.

    • I can actually think of ways this can be useful (beyond what others in this thread have dismissed), and might actually craft something as a proof-of-concept. Do you mind if I borrow/adapt some of your code as a starting point?



      • Hi Randy,

        feel free to use whatever you like. I'd suggest taking it from SVN where there's also a bit of documentation and a few basic tests.


  • Variable names in combination with strictures seem to me to enjoy more reliable compile-time detection than subs; as well, they’re easier to use in all sorts of ways (cf. the PBP arguments against the constant pragma).