SPUG: parsing a config file

Todd Wells toddw at wrq.com
Sun Jan 9 13:37:46 CST 2000


The *config file is generated by other software, and it is quite possible it
could be changed outside of my little perl program.  

-----Original Message-----
<deletia>

From: Sean Chittenden <sean at chittenden.org>

	Here's a question for you: who's going to be maintaining the
*config file?  If it's only going to be you (or some other perl
programmer), why not use Data::Dumper to save the state of the config
hash and read it in when the program is started?
	Or, if other people are going to be maintaining this, add a layer
of abstraction to the code that is evaled by the parent program.  Here's
some skeleton code trying to explain this if you didn't follow.

# To save data: reverse whatever load process you choose
# To load data:
my $configs = <CONFIG_FILE>;

# If you put evals in the $configs, the variables should
# be loaded into the current name space
eval $configs; if ($@) { die $@; }


####
# The config file looks like a dumped perl code (this is the layer of
# abstraction that I was talking about.  The layer allows you to pull info
# from all over the system/network).
#
# I'm using a file per variable just for an example.  Instead of files, it
# could be a regexp reading from an open file, it's up to you.  I use
# subroutines that use multiple regexps on the same file and IO::Socket
# to load config files.
#
# And, incase someone asks, the last variable is returned from the block.
# If I wanted to, I could use ($temp1, $temp2); as my last line and return
# an array;
#
# Last note, I use $temp instead of $_: it increases maintainability of
# code incase someone injects something before a line down the road.  <:)
my $config_hash = {
	# Get the domain
	domain = { open FILE, "<domain_file" or die "$!";
                   $temp = <FILE>;
                   close <FILE>; $temp; },
	admin = { open FILE, "<admin_file" or die "$!";
                  $temp = <FILE>;
                  close <FILE>; $temp; },
	[...]
};



	The code is pseudo code, but I think it gets the concept
across.  Layers and separation in a large projects are typically welcome
by all those involved except for those that are going into a project
ground zero and having to map out the problem.

-- 
Sean Chittenden                              <sean at chittenden.org>
fingerprint = 6988 8952 0030 D640 3138  C82F 0E9A DEF1 8F45 0466

Sir, it's very possible this asteroid is not stable.
		-- CP30


----- End forwarded message -----

-- 
*========================================================================*
| Tim Maher, PhD  Consultix &              (206) 781-UNIX/8649           |
|  Pacific Software Gurus, Inc             Email: tim at consultix-inc.com  |
|  UNIX/Linux & Perl Training              http://www.consultix-inc.com  |
| 2/22: UNIX  2/28: Perl Modules  2/29: Int. Perl  3/3: Pattern Matching |
*========================================================================*

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    POST TO: spug-list at pm.org        PROBLEMS: owner-spug-list at pm.org
 Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
 SUBSCRIBE/UNSUBSCRIBE: Replace ACTION below by subscribe or unsubscribe
        Email to majordomo at pm.org: ACTION spug-list your_address


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    POST TO: spug-list at pm.org        PROBLEMS: owner-spug-list at pm.org
 Seattle Perl Users Group (SPUG) Home Page: http://www.halcyon.com/spug/
 SUBSCRIBE/UNSUBSCRIBE: Replace ACTION below by subscribe or unsubscribe
        Email to majordomo at pm.org: ACTION spug-list your_address





More information about the spug-list mailing list