Config::IniFiles

[wardk]

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

[princepawn]

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.

[mjolnir]

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.

[wardk]

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

[metaperl]

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');

[demerphq]

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.

[mirod]

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

[wardk]

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

[1nickt]

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' );

[shagbark]

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.