Configuration files are a problem for both operating systems and applications. Where do you keep them, how are they structured?
Traditionally, Unix systems used text files with wildly varying internal structures, and Windows used either binary data or “.ini” text files (in this sense, “binary” is used for anything that you can’t access directly with a simple text editor). More recently, Windows abandoned .ini files in favor of a binary central registry.
The benefits of using a simple text format for configuration files should be obvious: nothing to learn (assuming that you can figure out WHAT to edit), and far more robust – no internal pointers to get screwed up, etc. The downside is that reading these files is slower, but realistically that is almost insignificant. There is also the annoyance of converting any required binary values to and from text, but again, that shouldn’t be anything that really slows down the reading or writing.
However, the ease of editing can be seen as a disadvantage also: if a proprietary tool is necessary for accessing the files, you can impose consistency checks and possibly avoid the introduction of garbage.
I lean toward text files. It is possible to provide validation tools that CAN be used, and even SHOULD be used under ordinary circumstances, while leaving the ability to directly edit raw text when circumstances are not ordinary. A good example of that philosophy is the “visudoers” command (see http://aplawrence.com/Basics/sudo.html ). You should use visudoers ordinarily, but if for some reason you could not, you can edit the /etc/sudoers file directly. Some systems provide special editors for the /etc/passwd file for the same reasons, and of course your normal “editing” of that is through other tools like “useradd” etc.
However, the structure of text configuration files is still a problem. Everything has its own format: /etc/passwd is nothing like /etc/sudoers and neither have any resemblance to /etc/fstab. There’s no common structure. Unix generally ignored this problem, but Windows tried “.ini” files to impose some consistency. Unfortunately, the .ini format doesn’t really cut it, because it’s just too simplistic. There have been some attempts to extend .ini to allow nesting and other features, but most agree that it just doesn’t have legs and isn’t a good solution. Windows didn’t drop .ini files entirely (they couldn’t, simply because of legacy concerns) but they did strongly discourage their use and also provided some integration of .ini into the Registry: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw98bk/html/inifilesversusregistry.asp
With Mac OS X, Apple has taken a different approach and uses XML property lists for most configuration data. Using XML provides a consistent data format that is easily hand or program edited.
For example, here’s the start of my ~/Library/Preferences/com.apple.internetconfig.plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
If we look carefully, it’s easy enough to find the home page setting there:
    <key>WWWHomePage</key>
       <dict>
         <key>ic-data</key>
         <string>http://www.pcunix.com/index.html</string>
       </dict>
and, of course, many other settings and preferences. Every Mac OS X app uses XML property lists too; see http://aplawrence.com/MacOSX/twosafaris.html for an example of those. Apple doesn’t suggest you edit plists directly, of course: there are tools for setting preferences and you should use these whenever possible. But knowing that I can edit these files easily gives me more confidence in my ability to diagnose and fix problems.
*Originally published at APLawrence.com
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
