http://qs1969.pair.com?node_id=35967

Item Description: A module for reading .ini-style configuration files.

Review Synopsis: I encountered a need for such a tool. Tried it, liked it. Time to share.

Module: Config::IniFiles

Author: Scott Hutton, currently maintained by Rich Bowen

Where is it? http://cpan.perl.org/modules/by-module/Config/RBOW/

Config::IniFiles is a module intended to make life easier for those who rely on flat configuration files. Specifically, files that use the "Windows style" format.

Config::IniFiles offers an easy and reliable method of reading and writing configuration files that utilize the Section key=value format. You can place the entire contents into a multil-dimensional hash, keyed on section, and/or easily pull those sections in their own hash.

I tried this module out as an alternative to what were/are multiple methods of "configuration" being used by my currrent client. Currently, my client's Perl CGI/batch scripts utilize a combination of database, hard-coding and tab-delimited flat files for setting default/site-specific configurations within the applications. Method used seems to depend on the author/maintainer of the day.

My intent was to implement the practice of a single standard method for storing configuration information. Although we develop and run on HP-UX, the development team that is responsible for maintenance and development are more comfortable with Windows and are all familiar with the "Windows style" configuration file format. I am referring to this style as "windows style", if a monk can identify this format properly, I will gladly update my use of this designation!

The style of configuration file is as follows:

[Section1] key1=value1 key2=value2 [Section2] key1=value1 key2=value2

I am sure you've been exposed to this formatting. If not, it is pretty self-explanatory.

My goal was to create a file similar to the following which would isolate common variables associated with the "current" environment that the Perl was executing in. In this case, dev/test/prod. The single configuration file would look similar to this (simplified for this example):

[prod] ORACLE_HOME=/path/to/oracle/prod ORACLE_SID=prod_sid [test] ORACLE_HOME=/path/to/oracle/test ORACLE_SID=test_sid [dev] ORACLE_HOME=/path/to/oracle/dev ORACLE_SID=dev_sid

The code itself determines which environment it is in based on the hostname

so lets proceed to using Config::IniFiles

# Make the module available use Config::IniFiles; # now nab the entire config file contents into the %ini hash my $ConfigFile = "/path/to/inifile/inifile"; tie my %ini, 'Config::IniFiles', (-file => $ConfigFile); # now grab the relevent section into it's own hash, we're assuming th +at it's "prod" for this example my %Config = %{$ini{"prod"}}; # now we have access to our keys in the hash print "Oracle home is $Config{ORACLE_HOME}"; print "Oracle SID is $Config{ORACLE_SID}";

While I haven't used all the features of this neat tool, here are a few features that would be real useful if we in fact utilize such a method.

- val ($section, $parameter) - Returns the value of the specified +parameter in section $section. - setval ($section, $parameter, $value, [ $value2, ... ]) - Sets t +he value of parameter $parameter in section $section to $value (or t +o a set of values). - newval($setion, $parameter, $value [, $value2, ...]) - Adds a new v +alue to the configuration file. - delval($section, $parameter) - Deletes the specified value from th +e configuration file - Sections - Returns an array containing section names in the configu +ration file. If the *nocase* option was turned on when the config object + was created, the section names will be returned in lowercase.

While I have yet to receive authorization to make such changes to my client's applications, I have a good tool for making it happen.

That is all for now...

Note: Updated typo 8/12/02 per demerphq's head up

Note: Updated 9/30/02 - modify <cite> tags to italic since cite wasn't

Replies are listed 'Best First'.
RE: Config::IniFiles
by metaperl (Curate) on Oct 11, 2000 at 20:44 UTC
    Actually, the Config::IniFiles handles win-style configuration files in a better manner.

    It allows access to variables by section and name, whereas with AppConfig you have to grok a name which is the concatenation of section and name. Thus:

    [db] user = bob pass = pass
    can be grokked in Config::IniFiles as
    $config->val('db','user');
    While AppConfig requires you first to define it as a variable and then to grok it:
    $config->define('db'); $config->get('db_user');
RE: Config::IniFiles
by princepawn (Parson) on Oct 09, 2000 at 22:14 UTC
    App::Config written by Andy Wardley (CPAN author id ABW), handles this configuration file type as well as others. It is a much older module (meaning, much more time to be debugged).

    We discussed App::Config as ameans of application configuration.

    I really sometimes think someone should reject these new modules if they dont offer any new functionality.

      Config::IniFiles can write as well as read config files. It is a better general method of reading INI files, whereas AppConfig is for more "known" config files.

      Oddly enough, princepawn I used YOUR post as a trigger to investigate config modules after coming across this situation here at work.

      How I ended up testing Config::IniFiles instead of App::Config is a bit of a mystery...

Re: Config::IniFiles
by demerphq (Chancellor) on Aug 07, 2002 at 12:32 UTC
    Hi. Nice node. Unfortunately it seems like some of our less enlightened brethren are getting thrown by the minor typo in your example
    print "Oracle home is $Config{"ORACLE_HOME"};
    Should read
    print "Oracle home is $Config{ORACLE_HOME}";
    And likewise for the other print() statement. Also apparently it isnt all too clear (to some, *sigh*) that the INI snippet you include is meant to go along with the code snippet. Maybe you could clarify that?

    Good post nonetheless. ++

    Yves / DeMerphq
    ---
    Writing a good benchmark isnt as easy as it might look.

RE: Config::IniFiles
by mirod (Canon) on Oct 09, 2000 at 23:44 UTC

    And of course XML::Simple allows you to work with XML configuration files...

      Good idea!

      Note that the site I am working on is all perl4 scripts, using cgi-lib...and it gets worse, it's also a completely modified version of cgi-lib. The original programmer renamed all the functions to "be compatible" with the application naming conventions. yikes.

      XML configuration would be nice, but I am not convinced I'll get to change the existing situation to anything standard, let alone an "emerging standard" like XML.

      rm -rf * && start_clean

Re: Config::IniFiles
by 1nickt (Canon) on Jun 24, 2015 at 01:41 UTC

    Config::Tiny is what I use for ini-style config files. It allows you to access the items close to how shagbark suggested:

    use Config::Tiny; my $ini = Config::Tiny->read( 'config.ini', 'utf8' ); my $foo = $ini->{bar}->{foo}; $foo = 'baz'; $ini->{bar}->{foo} = $foo; $ini->write( 'config.ini', 'utf8' );
Re: Config::IniFiles
by shagbark (Acolyte) on Mar 18, 2013 at 19:07 UTC
    Nice, but why do we have all these accessor functions? Why not just return a hash where each entry is converted to
    $hash{section}->{parameter} = $value

    Then it would be easy to make it work with other Perl code. For instance, I could print out all of the data that the config file loaded with a single library function call.