Perl Cookbook error?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
In chapter 8.16 "Reading configuration files" and using "do" to read  
perlish conf files they give the example of overriding a system file  
with a user file viz:

do "sysconf";
do "userconf";

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."

do "sysconf"
do "userconf";

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.
Dave Saville

Re: Perl Cookbook error?

Quoted text here. Click to load it

Yes, this is the wrong way around.

Quoted text here. Click to load it

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
a problem.

Quoted text here. Click to load it

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:

    use strict;
    our ($Foo, @Bar, %Baz);

    do "conf";

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 itself, since IME sometimes does strange things), or
JSON if you're more concerned about 'clean' formats and less concerned
about human-writability.


Re: Perl Cookbook error?

Quoted text here. Click to load it

Thanks for the confirmation Ben and the extra info.  I tried to submit
an errata report to O'Reilly but the link to do so throws an error.

Dave Saville

Site Timeline