Professional Web Applications Themes

Configuration File - PERL Beginners

Hi Perlers, I'm trying to implement one of the recipes I found in the Perl Cookbook. It is "8.16. Reading Configuration Files" recipe. Here are some snippets from that text: " ... Or better yet, treat the config file as full Perl code: do "$ENV{HOME}/.progrc"; .... The second solution uses do to pull in raw Perl code directly. When used with an expression instead of a block, do interprets the expression as a filename. This is nearly identical to using require, but without risk of taking a fatal exception. .... You might wonder what context those files will be executed ...

  1. #1

    Default Configuration File

    Hi Perlers,

    I'm trying to implement one of the recipes I found in the Perl
    Cookbook. It is "8.16. Reading Configuration Files" recipe. Here are
    some snippets from that text:

    " ... Or better yet, treat the config file as full Perl code:

    do "$ENV{HOME}/.progrc";
    ....
    The second solution uses do to pull in raw Perl code directly. When
    used with an expression instead of a block, do interprets the
    expression as a filename. This is nearly identical to using require,
    but without risk of taking a fatal exception.
    ....
    You might wonder what context those files will be executed under. They
    will be in the same package that do itself was compiled into.
    Typically you'll direct users to set particular variables, which,
    being unqualified globals, will end up in the current package. If
    you'd prefer unqualified variables go into a particular package, do
    this:

    { package Settings; do "$ENV{HOME}/.myprogrc" }

    As with a file read in using require or use, those read in using do
    count as a separate and unrelated lexical scope. That means the
    configuration file can't access its caller's lexical (my) variables,
    nor can the caller find any such variables that might have been set in
    the file. It also means that the user's code isn't held accountable to
    a pragma like use strict or use integer that may be in effect in the
    caller."


    My code looks like this (for testing):

    #!/usr/bin/perl
    # configtest.pl

    use warnings;
    use strict;

    { package Config; do "configtest.conf" }

    print "$_\n" for( Config::FILE_NAME );

    My configtest.conf file looks like this:

    # A list of file names
    FILE_NAME = qw[
    /This/is/a/test
    /This/is/also/a/test
    /And/this/is/the/last/test
    ];

    Now, this code runs, and produces the expected output. However, it
    also gives me a warning:
    Name "Config::FILE_NAME" used only once: possible typo at
    ../configtest.pl line 7.

    I realize I can just turn my pragmas off after testing/implementation
    to get rid of this, but is there a better way? Perhaps my Perl
    Cookbook is just old (yup, 1st edition. Has this recipe been
    updated?)

    --Errin
    Errin Guest

  2. #2

    Default Re: Configuration File

    Errin Ln wrote: 

    <snip>
     

    Nothing prevents you from declaring FILE_NAME:

    package Config;
    our FILE_NAME;
    do "configtest.conf";
    print "$_\n" for FILE_NAME;

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Guest

  3. #3

    Default Re: Configuration File

    On Thu, 30 Sep 2004 23:30:16 +0200, Gunnar Hjalmarsson
    <cc> wrote: 

    doesn't that kinda defeat the purpose of declaring the Config name
    space? I was trying to keep the variables in the configtest.conf file
    in a different name space than the main program. I don't HAVE to do
    this, just thought it seemed like a good way to keep the two,
    potentially conflicted, name spaces apart. I wanted to see the
    variables created in the Config name space require a dereference (is
    that the right word?), ala Config::FILE_NAME. That way, if the main
    code ALSO has a FILE_NAME variable, the contents of the (at run time,
    unknown to the main developer) config file.

    I hope that's making sense.

    --Errin
    Errin Guest

  4. #4

    Default Re: Configuration File

    Errin Ln wrote: 
    >
    > doesn't that kinda defeat the purpose of declaring the Config name
    > space?[/ref]

    Can't see how. It is being declared within package Config.
     

    That sounds wise, and I didn't suggest anything else.
     

    No. You mean require the fully qualified names.
     

    If you don't export anything from package Config, you still need to
    use the fully qualified names when calling those variables from other
    packages, so I don't think that's a reason either to not declare the
    variables in package Config.

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
    Gunnar Guest

Similar Threads

  1. Configuration file
    By Eric Kincl in forum PHP Development
    Replies: 1
    Last Post: November 20th, 02:12 AM
  2. Replies: 2
    Last Post: August 15th, 03:02 AM
  3. ASP.Net Configuration File
    By Joel Cade in forum ASP.NET General
    Replies: 1
    Last Post: July 16th, 07:47 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139