Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- Perl Cookbook error?
- Dave Saville
May 4, 2013, 4:25 pm
rate this thread
perlish conf files they give the example of overriding a system file
with a user file viz:
They then go on to say "if you want to ignore the system config file
when the user has his own test the return value of the do."
Is this not the wrong way around?
My take is that if there is *not* a userconf then the do will silently
fail. So the test needs to run the system file only if there is no
userfile as in
do "userconf" or do "systemconf";
Or have I got it wrong? Although a quick test seems to bear me out.
BTW, it seems one can't use strict when doing this type of thing.
Re: Perl Cookbook error?
Yes, this is the wrong way around.
This looks right to me, except for the fact that *any* failure in the
user file (including a file which ran entirely successfully but happened
to return a false value) will cause the system config to be read.
Depending on the circumstances a partially-applied user config might be
You can, but it's not entirely straightforward. The first restriction is
that 'strict' is lexically scoped, so it doesn't carry over into the
file run by 'do'; this means the user may well end up creating random
globals by accident. (But since you're presumably using strict in your
code, that doesn't matter as much as you might think.)
The second is that since, again, the do is in a separate lexical scope,
you have to use package variables to communicate between the two files.
So you end up with something like this:
our ($Foo, @Bar, %Baz);
and then the config can contain
$Foo = 123;
@Bar = qw/a b c/;
and the main config can pick up those variables. (Slightly strangely,
the current package *does* carry over into the do, so as long as the
user doesn't change package unqualified globals will show up in the
package you called do from.)
An alternative option is, instead of letting the user set globals, to
provide some set of subs for the user to call to set the configuration.
This is how RT works: the configuration file consists of a series of
statements, where the Set function is provided by RT and does whatever
is needed to get the information into the right place. (In fact the
first parameter to Set is a global variable in the current package, but
I assume this is just a hangover from some previous incarnation where
the config file used globals directly. For a new system there's no
reason not to use string keys.)
Other examples of configuration-in-Perl would be the Makefile.PL and
Build.PL files in CPAN distributions: in the common case, both look much
more like config files than they do like programs, but in complicated
cases Perl can be used to calculate the required config on the fly.
All in all, I don't think using Perl for config files is a very good
idea. Personally I would use YAML (and read it with YAML::XS, not
YAML.pm itself, since IME YAML.pm sometimes does strange things), or
JSON if you're more concerned about 'clean' formats and less concerned
- » Why do Perl programmers make more money than Python programmers
- — Next thread in » PERL Discussions