SPUG: parsing a config file

Tim Maher/CONSULTIX tim at consultix-inc.com
Sun Jan 9 02:12:26 CST 2000


Majordomo didn't like "config" in this one -

Tim

==========================================================
|  Tim Maher, Ph.D.           Tel/Fax: (206) 781-UNIX    |
|  SPUG Founder & Leader      Email: spug at halcyon.com    |
|  Seattle Perl Users Group   HTTP: www.halcyon.com/spug |
==========================================================

From: owner-spug-list at pm.org
Date: Sat, 8 Jan 2000 14:26:05 -0500 (EST)
X-Authentication-Warning: happyfunball.pm.org: mjordomo set sender to owner-spug-list at pm.org using -f
To: owner-spug-list at pm.org
Subject: BOUNCE spug-list at pm.org:     Admin request of type /^\s*config\b/i at line 2  

>From tim at consultix-inc.com  Sat Jan  8 14:26:03 2000
Received: from rand.csyn.net (dsl016180.midsl.net [216.190.16.180])
	by happyfunball.pm.org (8.9.3/8.9.1) with ESMTP id OAA26300
	for <spug-list at pm.org>; Sat, 8 Jan 2000 14:26:02 -0500 (EST)
Received: from localhost (sean at localhost)
	by rand.csyn.net (8.9.3/8.9.3) with ESMTP id LAA99115
	for <spug-list at pm.org>; Sat, 8 Jan 2000 11:26:39 -0800 (PST)
Date: Sat, 8 Jan 2000 11:26:34 -0800 (PST)
From: Sean Chittenden <sean at chittenden.org>
X-Sender: sean at rand.csyn.net
To: spug-list at pm.org
Subject: RE: SPUG: parsing a config file
In-Reply-To: <1654BC972546D31189DA00508B318AC8A57F61 at charmander.wrq.com>
Message-ID: <Pine.BSF.4.20.0001081107180.95002-100000 at rand.csyn.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	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





More information about the spug-list mailing list