Programmer's notebook: config files

Discussion in 'Perl Misc' started by Irving Kimura, Jan 18, 2004.

  1. I'm relatively new to Perl, and I'm still learning the basic patterns
    of good Perl programming. Here's one I'm having to deal with right
    now: config files.

    Often programs/scripts can have so many system-dependent options
    that it is not practical for them to be specified command-line
    flags. In these cases, a common strategy is to use configuration
    files that the program reads at start-up. What's your favorite
    way to handle system-dependent constants?

    One straightforward approach is to define a simple syntax for the
    configuration file (e.g. separate lines consisting of VAR=val pairs,
    plus comments and blank lines), and having one's program parse this
    file to get the configuration parameters to use.

    But as I learn more about Perl, I see that another possibility is
    to have a file (e.g. My_Module/Constants.pm) with format such as
    this:

    package My_Module::Constants;
    use constant VAR1 => var1;
    use constant VAR2 => var2;
    # etc.

    and then put the line

    use My_Module::Constants;

    at the beginning of every script that needs these configuration
    variables. Then, the rest of the code can use these configuration
    variables like this: my $foobar = My_Module::Constants::VAR1.
    One advantage this approach has over the previous one is that it
    gets perl to parse the config file for us.

    This last technique looks to me like the way to go, at least for
    programs that are expected to pay attention to no more than one
    configuration file (as opposed to those that must deal with end-user
    customizations), but I'm still too green with Perl, and I wonder
    what pitfalls this approach may have, and whether there is a better
    way to accomplish this task in Perl (yeah, I know about TMTOWTDI).

    Thanks for your comments.

    Irv
     
    Irving Kimura, Jan 18, 2004
    #1
    1. Advertising

  2. Irving Kimura

    gnari Guest

    "Irving Kimura" <> wrote in message
    news:bueq2k$m2a$...
    >

    [snipped discussion about config files]
    > ...
    > But as I learn more about Perl, I see that another possibility is
    > to have a file (e.g. My_Module/Constants.pm) with format such as
    > this:
    > ...
    > and then put the line
    >
    > use My_Module::Constants;
    >
    > at the beginning of every script that needs these configuration
    > variables. Then, the rest of the code can use these configuration
    > variables like this: my $foobar = My_Module::Constants::VAR1.
    > One advantage this approach has over the previous one is that it
    > gets perl to parse the config file for us.


    it all depends, of course.
    it depends on whether the config is changed/set at install time
    or frequently.
    it depends on whether the config should be user-editable
    it depends on whether the scripts using it are all in one location,
    or if they are scattered all over, and maybe run by different users.

    you have a few possibilities:
    local configuration file, parsed by program/module
    global configuration file (/etc or something)
    require conf.pl
    use MyModule::Conf

    the module is pleasant if it needs to be used by various scripts,
    say cgi, admin and cron scripts, all run under different environments,
    and by different users. then there is no problem finding the config,
    the 'use' command finds it for you.
    the downside is that it is slightly more trouble if you need to edit it.
    in that case you might have the module contain the location of the
    editable conffile.

    gnari
     
    gnari, Jan 18, 2004
    #2
    1. Advertising

  3. Irving Kimura <> wrote:

    > use constant VAR1 => var1;

    ^^^
    ^^^

    That is a strange choice of name for something that is not variable. :)


    --
    Tad McClellan SGML consulting
    Perl programming
    Fort Worth, Texas
     
    Tad McClellan, Jan 18, 2004
    #3
  4. Irving Kimura

    Anno Siegel Guest

    Irving Kimura <> wrote in comp.lang.perl.misc:
    >
    >
    >
    > I'm relatively new to Perl, and I'm still learning the basic patterns
    > of good Perl programming. Here's one I'm having to deal with right
    > now: config files.
    >
    > Often programs/scripts can have so many system-dependent options
    > that it is not practical for them to be specified command-line
    > flags. In these cases, a common strategy is to use configuration
    > files that the program reads at start-up. What's your favorite
    > way to handle system-dependent constants?
    >
    > One straightforward approach is to define a simple syntax for the
    > configuration file (e.g. separate lines consisting of VAR=val pairs,
    > plus comments and blank lines), and having one's program parse this
    > file to get the configuration parameters to use.


    There are a few modules on CPAN that do that. A colleague of mine
    has been using Config::IniFiles to configure a print server. It
    has supported 2500+ lines of configuration data with lots of changes
    over the last few years, but there are other modules.

    > But as I learn more about Perl, I see that another possibility is
    > to have a file (e.g. My_Module/Constants.pm) with format such as
    > this:
    >
    > package My_Module::Constants;
    > use constant VAR1 => var1;
    > use constant VAR2 => var2;
    > # etc.
    >
    > and then put the line
    >
    > use My_Module::Constants;
    >
    > at the beginning of every script that needs these configuration
    > variables. Then, the rest of the code can use these configuration
    > variables like this: my $foobar = My_Module::Constants::VAR1.
    > One advantage this approach has over the previous one is that it
    > gets perl to parse the config file for us.


    [advantages of this approach]

    That's always an alternative. There are also downsides.

    Maintainers of the configuration must understand some Perl to do their
    job. They also must be trusted since they can make the final job do
    *anything*.

    It also blurs the distinction between code and data. There will always
    be a temptation to put a little routine or two in the configuration
    file because it's convenient. If you don't exercise strict discipline,
    you end up with stuff in the configuration that doesn't belong there.

    Anno
     
    Anno Siegel, Jan 19, 2004
    #4
  5. In <bugh9g$62n$-Berlin.DE> -berlin.de (Anno Siegel) writes:

    >Maintainers of the configuration [...]
    >must be trusted since they can make the final job do
    >*anything*.


    I see. But wouldn't this concern apply to any easily editable
    script?

    >It also blurs the distinction between code and data. There will always
    >be a temptation to put a little routine or two in the configuration
    >file because it's convenient. If you don't exercise strict discipline,
    >you end up with stuff in the configuration that doesn't belong there.


    Good point.

    This is very useful feedback. Thank you very much.

    Irv
     
    Irving Kimura, Jan 19, 2004
    #5
  6. Irving Kimura

    Anno Siegel Guest

    Irving Kimura <> wrote in comp.lang.perl.misc:
    > In <bugh9g$62n$-Berlin.DE>
    > -berlin.de (Anno Siegel) writes:
    >
    > >Maintainers of the configuration [...]
    > >must be trusted since they can make the final job do
    > >*anything*.

    >
    > I see. But wouldn't this concern apply to any easily editable
    > script?


    Yes, but unlike a config file, normal scripts don't *have* to be easily
    editable.

    Anno
     
    Anno Siegel, Jan 19, 2004
    #6
  7. Irving Kimura

    bill Guest

    In <bugjt7$8go$> Irving Kimura <> writes:

    >In <bugh9g$62n$-Berlin.DE> -berlin.de (Anno Siegel) writes:


    >>Maintainers of the configuration [...]
    >>must be trusted since they can make the final job do
    >>*anything*.


    >I see. But wouldn't this concern apply to any easily editable
    >script?


    Just run the rest of your script through an obfuscator.

    bill
     
    bill, Jan 19, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. CSharpner
    Replies:
    0
    Views:
    1,141
    CSharpner
    Apr 9, 2007
  2. Sanny
    Replies:
    391
    Views:
    42,867
    anish.mathew84
    Jan 6, 2010
  3. Sanny
    Replies:
    396
    Views:
    7,306
    Noah Roberts
    Dec 17, 2008
  4. Irving Kimura
    Replies:
    6
    Views:
    305
    Charles DeRykus
    Feb 3, 2004
  5. Irving Kimura
    Replies:
    2
    Views:
    264
    Tassilo v. Parseval
    Jan 30, 2004
Loading...

Share This Page