Configuration File

You might consider moving many of those variables (ftp host, ftp user, email address, log directory, etc) into a configuration file. That would allow you to change these values in the future, without touching the source code. The config file could even be located in a place where your operations staff (if you have one) can modify it, allowing them to do things like update an email address without involving you at all.

I like to use Config::IniFiles (available on CPAN) for this purpose. I generally tie it to a hash, reducing the number of global variables that I have to keep track of.

Here's a sample config.ini file. It has separate values for testing and production, making it easy to switch from one to the other:

[prod]
ftp_host   = ftp.uslec.net
ftp_user   = cheese
ftp_pass   = whiz
log_method = both
def_email  = someone@somewhere.com
LOGFILE    = /u20/home/gvc/log/something.log
[test]
ftp_host   = ftp.uslec.net
ftp_user   = cheesetest
ftp_pass   = whiztest
log_method = both
def_email  = someonetest@somewhere.com
LOGFILE    = /u20/home/gvc/log/somethingtest.log
[download]

Here's a sample code snippet:

use Config::IniFiles;
our (%cfg);
my %ini;
tie %ini, 'Config::IniFiles', (-file => "config.ini");
%cfg = %{$ini{'prod'}};
print "I will FTP files to" . $cfg{ftp_host};
[download]

Wally Hartshorn

Comment on Configuration File Select or Download Code

Replies are listed 'Best First'.
Re: Configuration File by gnu@perl (Pilgrim) on Dec 06, 2002 at 16:44 UTC
I had considered moving some of the things to a config file, but I wanted this to be somewhat self contained. The idea was that the default server (ftp.uslec.net) with the default login would be used if nothing is specified on the command line. The user does have the ability to use other servers by naming them on the command line with their appropriate login/pass combo. Part of the purpose of this program was to allow users to ftp to a server where they normally don't have access rights. Keeping the default server/login/pass in the code fulfilled that need. The security of the information is maintained by having no read rights on the program for the users, only execute rights. This 'security' is of course no different than if the info was in a config file with similar access control. I do really like the idea of using config files for most things and dislike hard coding informatin, but for this purpose I could find no better way to do it. Thanks for the tip on Config::IniFiles, I had not used that before but I definately will use it for my next project.	[reply]

Replies are listed 'Best First'.

Re: Configuration File
by gnu@perl (Pilgrim) on Dec 06, 2002 at 16:44 UTC

The user does have the ability to use other servers by naming them on the command line with their appropriate login/pass combo.

Part of the purpose of this program was to allow users to ftp to a server where they normally don't have access rights. Keeping the default server/login/pass in the code fulfilled that need. The security of the information is maintained by having no read rights on the program for the users, only execute rights. This 'security' is of course no different than if the info was in a config file with similar access control.

I do really like the idea of using config files for most things and dislike hard coding informatin, but for this purpose I could find no better way to do it. Thanks for the tip on Config::IniFiles, I had not used that before but I definately will use it for my next project.

[reply]