Re: Simple Configuration Parser

The way we do config files here (not sure how common the approach is) is to make the config file a hash...ie:

{    
    confval1 => 'foo',
    confval2 => {
        'bar' => 'baz'
    },
# etc..
}
[download]

You get the idea. You just snarf the file, eval it, and boom, you have a hash of config values.

this has really helped us get stuff configurable quickly, and I don't really see many drawbacks, as long as you take care who can read/write the conf.

Comments?

Trinary

Comment on Re: Simple Configuration Parser Download Code

Replies are listed 'Best First'.
Re (tilly) 2: Simple Configuration Parser by tilly (Archbishop) on Mar 12, 2001 at 11:27 UTC
I do something similar. What I really like about this approach is that I can have a path where configuration files are kept. There is no need to stop at the first one. Instead you pick them up in turn, later ones override the first. This is nice because it allows you to have later files override only what they need to. For an example of how to use this consider the case where your path goes through a CVS directory and winds up out of CVS. Then developers can try changing a few defaults here and there without changing files in CVS and running the risk of checking in something that was meant to be part of a private test...	[reply]

Replies are listed 'Best First'.

Re (tilly) 2: Simple Configuration Parser
by tilly (Archbishop) on Mar 12, 2001 at 11:27 UTC

This is nice because it allows you to have later files override only what they need to. For an example of how to use this consider the case where your path goes through a CVS directory and winds up out of CVS. Then developers can try changing a few defaults here and there without changing files in CVS and running the risk of checking in something that was meant to be part of a private test...

[reply]