Reading configuration files

Most programmers have probably written code to process text files like this at one time or another. In some languages, this is easy; in some it's more difficult. But it's always about the same algorithm: You loop over the lines of the file and parse the strings that you get back. On Windows systems, there are convenient functions for accessing data in the INI file format: GetProfileString()and SetProfileString().

[section1]
name1=value1
name2=value2
[section2]
someothername=someothervalue

In this article, I'm going to propose an XML version of the configuration file format (see Example 2), and explore several ways to get information out of files in this format using Perl. We'll end up with our own versions of getProfileString() and setProfileString() that provide transparent access to XML configuration files.

A simple configuration file format in XML

<configuration-file>
<section name="section1">
  <entry name="name1" value="value1"/>
  <entry name="name2" value="value2"/>
</section>
<section name="section2">
  <entry name="someothername" value="someothervalue"/>
</section>
</configuration-file>

A DTD for this format can be seen in Figure 1.

<!ELEMENT configuration-file (section+)>

<!ELEMENT section (entry*)>
<!ATTLIST section
        name    CDATA    #REQUIRED
>

<!ELEMENT entry EMPTY>
<!ATTLIST entry
        name    CDATA    #REQUIRED
        value   CDATA    #REQUIRED
>

The DTD serves mainly as documentation for the intended format; in practice, we're going to treat XML INI files as simple well-formed documents.

XML files aren't lines of text

Example 4. INI file with different line breaks.

<configuration-file><section name="section1">
<entry
name="name1"
value="value1"/><entry name="name2"
value="value2"/>
</section><section name="section2"
>
<entry name="someothername" value="someothervalue"/>
</section>
</configuration-file>

If you're willing to reinvent the lexical analysis of XML files, you could process this one line at a time, but it's not worth the effort.

Brute force: Using regular expressions

  1 |sub getProfileString {
    |    my ($xmlfile, $section, $variable, $default) = @_;
    |    local (*F, $_);
    |
  5 |    open (F, $xmlfile) || return undef;                    # Load the document
    |    read (F, $_, -s $xmlfile);
    |    close (F);
    |
    |    while (/(<section[^>]*>)(.*?)<\/section\s*>/s) {       # Process sections
 10 |        my($sectstart) = $1;                               # Save start tag
    |        my($sectdata) = $2;
    |        $_ = $';
    |
    |        if ($sectstart =~ /name=([\"\'])$section\1/s) {    # Process entrys
 15 |            while ($sectdata =~ /<entry[^>]*?\/>/) {
    |                my($entry) = $&;
    |                $sectdata = $';
    |                if ($entry =~ /name=([\"\'])$variable\1/s) {
    |                    if ($entry =~ /value=([\"\'])(.*?)\1/s) {
 20 |                        return $2;
    |                    } else {
    |                        return "";
    |                    }
    |                }
 25 |            }
    |            return $default;
    |        }
    |    }
    |    
 30 |    return $default;
    |}

This code has four important features:

Line 5		The entire document is loaded into memory. This avoids the problems associated with reading an XML file line-by-line, and allows us to match elements that contain newlines in “unexpected” places.
Line 9		The document is processed a section at a time. The regular expression /(<section[^>]*>)(.*?)<\/section\s*>/s matches an entire section, from start-tag to end-tag. Note how the regular expressions for the start- and end-tags allow for the possibility of whitespace, and the use of the /s modifier to allow Perl to match across newlines. (Beware that this code would not work properly if <section> tags could be nested.) Matching large regular expressions can have a performance impact, although the impact is probably insignificant for small files such as these. If you're tempted to use this method on larger files, the impact may be worth considering. For a complete discussion of regular expressions, see Mastering Regular Expressions by Jeffrey Friedl.
Line 10		The start-tag for the section is stored in a variable. By storing the start-tags in variables, we can examine them (using another regular expression) for the attributes we're after. Since attributes can occur in any order, matching in one step quickly leads to extremely hairy regular expressions.
Line 15		Once we find a section with the name we're after, we perform an analogous parse of the entries within that section.

A more complete solution

Conclusion