> Well, any other ideas on how I can have a hundred scripts all use the
> same settings and make it easy to change any of them at will without
> having to go edit a hundred files would be nice.
> ... 
> To share configuration variables in one place for lots and lots of
> scripts to use instead of having to put them in each script and then
> on echanges and having to go through a hundred scripts all over the
> place to change them.

Sounds like you have a reasonably well-planned solution, and I think
it'll work. Still, you might consider making a proper module.
e.g.:

the configurator :)
===================

package Configurator;

our %value;

sub import {
  for (<DATA>) {
       chomp;
       my($k,$v) = split /=/;
       $value{$k} = $v;
  }
}
1;

__DATA__
key1=value1
other=whatever


now, in your script:
====================
use Configurator;
print "$Configurator::value{other}\n";

output:
=======
whatever

It probably seems convoluted and contrived, but then every script that
uses the Configurator (or whatever you call it :) will have access to
the same data, editable and alterable in the one location after the
__DATA__ tag in the module itself.

More importantly, you can then put other tools such as utility
functions in it, and they'll be there for all scripts using them
without potentially polluting your namespace. Then you're only a couple
of steps away from writing full-blown object modules, and as your
project expands, you can completely retool the configuration system
underlying the module, maybe to use a real database and some serious
conditionals.... but scripts using the object interface wouldn't have
to be changed. Replacing the engine wouldn't require a new steering
wheel.

  my $conf = new Configurator @arglist or die "Can't initialize: $!";
  if ($conf->ready) { 
      do_stuff();
  } else {
      $conf->update or $conf->something_else;
  }

You get the idea. What's going on in the object? An oracle database
interface? MySQL? A DBM file? Maybe just a flatfile read, or even the
simplistic <DATA> read from stuff inside the module file itself? You
don't know without opening the module, and so the scripts coded that
way don't have to care. :)

Scalability! =o)

Could you do that with a do() or require()? Probably, but it's
nonstandard, and use() has more tools and toys built in. Use() it. :)

__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to