in reply to Configuration file design

First rule for user editable config files, specially if the file needs to be edit often is to be very, very liberal in what you accept. This would rule out XML, Yaml or Perl code solution. It also means that if there are two obvious ways of putting things in the file, you should accept both. And a third way.

Second rule is that it should be simple, which again would rule out XML, Yaml and Perl code.

I might format the config file like this: 

root     = /path/to/root
filepath = /path/to/files

server = ftp1
    sourcepath = /source/path/on/server
    savepath   = /save/files/here

server = ftp2
    savepath   = /files/go/here
    sourcepath = /some/path/somewhere
I've been using, and still use, lots of configuration files in different formats (most of them just for personal use). And while I try to make them have more or less the same syntax, I often find that every project benefits from a different syntax.

Some parsers I've used are simply line based, using hardly anything more than split. Sometimes, I write a Parse::RecDescent grammar.

Replies are listed 'Best First'.
Re^2: Configuration file design
by castaway (Parson) on Jan 05, 2005 at 08:33 UTC
    I quite like this suggestion, since it still just involves X=Y lines and not sections, and if I give the variables meaningfull names (similar to how they are referenced in the documentation), it will probably work quite well.

    I agree, by the way, the config file should be as simple and liberal as possible, and accept a variety ways of doing things, even if it makes the parsing code complex. (It should be easy for them, not me), which is why I'm also ruling out using Perl, XML, YAML and so on.

    Thanks, C.

[reply]

In Section Meditations