Re: Single file oriented for different usage

We use a package called Config::Inifiles for all of our configuration files. You can have sections in a file that have headings and load information from each of the headings in your code. You should be able to make a [GLOBAL] setting and a [DEV] section. You should probably include a second ini file for the authentication information though and have your package expect there to be two files (one with GLOBAL/DEV settings and one with AUTH information).

Comment on Re: Single file oriented for different usage

Replies are listed 'Best First'.
Re^2: Single file oriented for different usage by arbingersys (Pilgrim) on Feb 26, 2008 at 18:35 UTC
Thanks, that could work. I'll definitely check it out. A blog among millions.	[reply]
Re^2: Single file oriented for different usage by doom (Deacon) on Feb 27, 2008 at 19:47 UTC
Yes, I was going to suggest something similar: Config::ApacheFormat lets you use Apache-style configuration files for other purposes, so you can, for example, override the global definitions based on path.	[reply]
Re^2: Single file oriented for different usage by ack (Deacon) on Feb 28, 2008 at 15:44 UTC
I have used a similar approach (though I've never used Config::Inifiles...somehow I missed it...I'm going to check it out) and it works pretty well for us. In our case we develop on Win32 systems and then run the applications on Unix systems...so we use different Config files to handle the differences between Win32 and Unix. The authentication is interesting to me as we've recently been looking at requiring login + authentication on our applications to ensure that only folks authorized to be commanding our systems are allowed to do so (we already have a login layer just to get on the command & control computers and that's been good enough so far...but we're in the midst of some changes that make that vulnerable). So I've been considering having a development login and an operations login. So this thread is especially interesting to me. ack Albuquerque, NM	[reply]