in reply to How do you load configuration variables

Hardcode¹ the path to a config file and put everything you need in there.

1. Don't hardcode it more than once though... use a constant or global variable near the beginning of your program where it will be easy to find.

"My two cents aren't worth a dime.";
  • Comment on Re: How do you load configuration variables

Replies are listed 'Best First'.
Re: Re: How do you load configuration variables
by Excalibor (Pilgrim) on Jul 13, 2003 at 22:14 UTC

    I always create a module to handle program configuration, and I always call it Program::RC

    Then Program::RC has a method new that instantiates an object that reads the configuration from whereever it is stored (config file, la windows INI file is pretty good, with permissions well set so as to protect sensitive data), database, LDAP directory, whatever.

    The class offers a series of methods to access the different parts of the configuration file and give the variables values.

    This approach has one added advantage, each time you instantiate a configuration object, the config file is read, so you can change the configuration and test it on the fly, not even a SIGHUP is needed.

    An example:

    use Foo::RC; # prepare things ... # now fork if ( my $pid = fork() ) { my $ret = process_request( @ data ); # ... other hooks, or whatever } else { ... } sub process_request { # blah blah blah my $rc = new Foo::RC; my ($server_ip, $server_port, $bind_dn, $bind_passwd) = $rc->get_ldap_server_data; # ... }

    Each time the program has to process a request, it reads its configuration. Unless it's a huge config file, this is almost unnoticeable delay, and you can always memoize or create a cache for this system once it's production time (this is really useful to developing/debugging...)

    good luck,

    NB: as I usually use Net::Server to make these things, the fork code can be wrong, please forgive me...

    our $Perl6 is Fantastic;

      I always create a module to handle program configuration, and I always call it Program::RC

      Why not just write that module once, name it once, and then reuse it in each application? Better yet, why not just use a module that already exists for just such a purpose; something like AppConfig, for instance?

      No matter how you access your config file — AppConfig, a home-brewed module, do $config or die $!, whatever — it's still best to hardcode the path in your program and allow it to be overridden with command-line args or envariables as necessary.

      "My two cents aren't worth a dime.";

        Hi there,

        It's a good question, and it deserves a good answer: I cannot always choose my config files format. So my Foo::RC will create an abstraction layer on top of the config file.

        Another goo reason is that this way I create the interfaces I like (which I would have anyway to write better code, eg.:

        my $rc = new Foo:RC; my $ldap = Net::LDAP->new( $rc->ldap_data ); $ldap->bind( $rc->ldap_bind_data ) or die $@;

        Among a wide amount of possible situations.

        Granted, Foo::RC would use AppConfig or any other of the configuration modules available in CPAN. But when you have to read INI files, normal /etc/* kind of config files (hence calling the module RC), XML config files or config data stored in a LDAP directory, Foo::RC makes a lot of sense and life much more easier...

        Best regards,

        our $Perl6 is Fantastic;