in reply to Configuration files

Ok, remembering I'm a newbie here, correct me if reponding to my own post like this is bad form . . .

all responses to date have been very enlightening - and greatly appreciated!

It has become very clear that the inability to install modules is certainly not an obstacle to actually using them, enven in the restrictive environment I am writing for. The only hurdle is actually choosing the best one for the project at hand.

So, what about thoughts on the do() method I described initially? Are there any real reasons NOT to use this method?

Thanks again!

Replies are listed 'Best First'.
Re^2: Configuration files
by BUU (Prior) on Jan 01, 2005 at 19:51 UTC
    1) Security. Any code placed in the config file will be executed with the same permissions as the script itself. This may or may not be a problem.

    2) Ease of use. Perl typically isn't the easiest language to use for simple configuration options, unless you're already fluent in it. Theres no real reason to require the some what complicated ( compared to yaml, config::simple, etc ) syntax of Perl unless you really need it's power. And for a simple config file, it doesn't sound like you do.
[reply]
      1) I don't think this is a problem. I'm pretty diligent about checking the permissions of the config to ensure the permissions don't allow anyone other than the intended user to make changes to it. The config must be executed with the same permissions as the calling script, so that's the desired affect.

      2) This one comes down to situation. Some of the stuff I've considered this for, I'm only doing because it's my own system and I'm playing admin for those users I wouldn't want to ask to write any config, however simple (no good making Mom learn Perl when she struggles with email :).
      In other situations, I expect those installing and configuring the utility to be at least perl initiates if not adepts - and I comment my packaged configs almost to the point of TMI. Regardless, I only use it for tools others have to manage when I'm in an environment where I am justified in my opposition to administration by monkeys. Even then, I try to comment enough to give even a monkey no excuse for screwing it up.

      * So, it appears the only real downside is the extra (minor) hoops I have to jump through to ensure the config can't be tampered with by anyone other than the calling userid, and the complexity left on the shoulders of the person actually configuring the tool.

      Am I right?

      * Another question is one of scope. I mentioned that I always use strict in these scripts, and limit all vars to "my" scope except those intended to be overridden by the config, which are put under "our" scope. This is one thing I'm not terribly confident of my understanding. Can the config modify the values of "my" scoped vars, or is it limited to modifying "our" scoped vars?

      Of course, I know that my current technique doesn't prevent the config from running off on its own tangent during the config process.

      Thanks again!
[reply]
        Lexical variables (those declared with my) are scoped to whichever block they happen to be in and are not accessible outside of that block (with the exception of references and closures). Note that their is an implicit "file scope" for every source file. So my variables declared in a file that is required will not be accessible from outside of that file. This is what globals declared with our are for.
[reply]

In Section Seekers of Perl Wisdom