Config::Grammar(3)

πŸ’– NAME πŸ’–

Config::Grammar β€” A grammar-based, user-friendly config parser. This is the Config::Grammar(3) page, bestie, and it's giving parser main-character energy. πŸ’…


✨ SYNOPSIS ✨

Okay so here's the whole vibe in a few lines, no cap:

use Config::Grammar;

my $args = { encoding => 'utf8' }; # the second parameter to parse() is optional
my $parser = Config::Grammar->new(\%grammar);
my $cfg = $parser->parse('app.cfg', $args) or die "ERROR: $parser->{err}\n";
my $pod = $parser->makepod();
my $ex = $parser->maketmpl('TOP','SubNode');
my $minex = $parser->maketmplmin('TOP','SubNode');

🌸 DESCRIPTION 🌸

Config::Grammar is literally a module to parse configuration files. The optional second parameter to the parse() method can be used to specify the file encoding to use for opening the file β€” see the documentation for Perl's use open pragma. 🫢

Your configuration can have multiple-level sections with assignments and tabular data. The parsed data gets returned as a hash containing the whole configuration. Config::Grammar uses a grammar that you supply when you create a Config::Grammar object, and it parses the configuration file and gives you helpful error messages if there's a syntax error. Using the makepod method you can generate documentation of the configuration file format. ✨

The maketmpl method can generate a template configuration file. Heads up though: if your grammar contains regexp matches, the template will not be all that helpful, because Config::Grammar is not smart enough to give you sensible template data based in regular expressions. 😭 The related function maketmplmin generates a minimal configuration template without examples, regexps or comments, and thus allows an experienced user to fill in the configuration data more efficiently. Slay. πŸ’…

🧚 Grammar Definition 🧚

The grammar is a multiple-level hash of hashes, which follows the structure of the configuration. Each section or variable is represented by a hash with the same structure. Each hash contains special keys starting with an underscore β€” such as _sections, _vars, _sub or _re β€” to denote meta data with information about that section or variable. Other keys are used to structure the hash according to the same nesting structure of the configuration itself. The starting hash you pass to new contains the "root section". πŸ‘‘

πŸ’… Special Section Keys πŸ’…

  • _sections β€” Array containing the list of sub-sections of this section. Each sub-section must then be represented by a sub-hash in this hash with the same name of the sub-section.

The sub-section can also be a regular expression denoted by the syntax /re/, where re is the regular-expression. In case a regular expression is used, a sub-hash named with the same /re/ must be included in this hash.

  • _vars β€” Array containing the list of variables (assignments) in this section. Analogous to sections, regular expressions can be used.
  • _mandatory β€” Array containing the list of mandatory sections and variables.
  • _inherited β€” Array containing the list of the variables that should be assigned the same value as in the parent section if nothing is specified here.
  • _table β€” Hash containing the table grammar (see Special Table Keys). If not specified, no table is allowed in this section. The grammar of the columns, if specified, is given by sub-hashes named with the column number.
  • _text β€” Section contains free-form text. Only sections and @includes statements will be interpreted; the rest will be added in the returned hash under _text as string.

_text is a hash reference which can contain a _re and a _re_error key which will be used to scrutanize the text ... if the hash is empty, all text will be accepted.

  • _order β€” If defined, a _order element will be put in every hash containing the sections with a number that determines the order in which the sections were defined.
  • _doc β€” Describes what this section is about.
  • _sub β€” A function pointer. It is called for every instance of this section, with the real name of the section passed as its first argument. This is probably only useful for the regexp sections. If the function returns a defined value it is assumed that the test was not successful and an error is generated with the returned string as content.

πŸ¦‹ Special Variable Keys πŸ¦‹

  • _re β€” Regular expression upon which the value will be checked.
  • _re_error β€” String containing the returned error in case the regular expression doesn't match (if not specified, a generic 'syntax error' message will be returned).
  • _sub β€” A function pointer. It called for every value, with the value passed as its first argument. If the function returns a defined value it is assumed that the test was not successful and an error is generated with the returned string as content.

If the _varlist key (see above) is defined in this section, the _sub function will also receive an array reference as the second argument. The array contains a list of those variables already defined in the same section. This can be used to enforce the order of the variables.

  • _default β€” A default value that will be assigned to the variable if none is specified or inherited.
  • _doc β€” Description of the variable.
  • _example β€” A one line example for the content of this variable.

πŸŽ€ Special Table Keys πŸŽ€

  • _columns β€” Number of columns. If not specified, it will not be enforced.
  • _key β€” If defined, the specified column number will be used as key in a hash in the returned hash. If not defined, the returned hash will contain a _table element with the contents of the table as array. The rows of the tables are stored as arrays.
  • _sub β€” they work analog to the description in the previous section.
  • _doc β€” describes the content of the column.
  • _example β€” example for the content of this column.

🌈 Special Text Keys 🌈

  • _re β€” Regular expression upon which the text will be checked (everything as a single line).
  • _re_error β€” String containing the returned error in case the regular expression doesn't match (if not specified, a generic 'syntax error' message will be returned).
  • _sub β€” they work analog to the description in the previous section.
  • _doc β€” Ditto.
  • _example β€” Potential multi line example for the content of this text section.

🧚 Configuration Syntax 🧚

⭐ General Syntax ⭐

  • A '#' denotes a comment up to the end-of-line, empty lines are allowed and space at the beginning and end of lines is trimmed.
  • A '\' at the end of the line marks a continued line on the next line. A single space will be inserted between the concatenated lines.
  • '@include filename' is used to include another file. Include works relative to the directory where the parent file is in.
  • '@define a some value' will replace all occurrences of 'a' in the following text with 'some value'.
  • Fields in tables that contain white space can be enclosed in either ' or ". Whitespace can also be escaped with \. Quotes inside quotes are allowed but must be escaped with a backslash as well.

⭐ Sections ⭐

Config::Grammar supports hierarchical configurations through sections, whose syntax is as follows:

  • Level 1: *** section name ***
  • Level 2: + section name
  • Level 3: ++ section name
  • Level n, n>1: +..+ section name (number of '+' determines level)

⭐ Assignments ⭐

Assignments take the form: 'variable = value', where value can be any string (can contain whitespaces and special characters). The spaces before and after the equal sign are optional. ✨

⭐ Tabular Data ⭐

The data is interpreted as one or more columns separated by spaces.

πŸ“ Example πŸ“

Okay bestie, here's the whole example β€” code first, then the configuration. πŸŽ€

πŸ’» Code πŸ’»

use Data::Dumper;
use Config::Grammar;

my $RE_IP       = '\d+\.\d+\.\d+\.\d+';
my $RE_MAC      = '[0-9a-f]{2}(?::[0-9a-f]{2}){5}';
my $RE_HOST     = '\S+';

my $parser = Config::Grammar->new({
  _sections => [ 'network', 'hosts' ],
  network => {
     _vars     => [ 'dns' ],
     _sections => [ "/$RE_IP/" ],
     dns       => {
        _doc => "address of the dns server",
        _example => "ns1.oetiker.xs",
        _re => $RE_HOST,
        _re_error =>
           'dns must be an host name or ip address',
        },
     "/$RE_IP/" => {
        _doc    => "Ip Adress",
        _example => '10.2.3.2',
        _vars   => [ 'netmask', 'gateway' ],
        netmask => {
           _doc => "Netmask",
           _example => "255.255.255.0",
           _re => $RE_IP,
           _re_error =>
              'netmask must be a dotted ip address'
           },
        gateway => {
           _doc => "Default Gateway address in IP notation",
           _example => "10.22.12.1",
           _re => $RE_IP,
           _re_error =>
              'gateway must be a dotted ip address' },
        },
     },
  hosts => {
     _doc => "Details about the hosts",
     _table  => {
         _doc => "Description of all the Hosts",
        _key => 0,
        _columns => 3,
        0 => {
           _doc => "Ethernet Address",
           _example => "0:3:3:d:a:3:dd:a:cd",
           _re => $RE_MAC,
           _re_error =>
              'first column must be an ethernet mac address',
           },
        1 => {
           _doc => "IP Address",
           _example => "10.11.23.1",
           _re => $RE_IP,
           _re_error =>
              'second column must be a dotted ip address',
           },
        2 => {
           _doc => "Host Name",
           _example => "tardis",
            },
        },
     },
  });

my $args = { encoding => 'utf8' }; # the second parameter to parse() is optional
my $cfg = $parser->parse('test.cfg', $args) or
  die "ERROR: $parser->{err}\n";
print Dumper($cfg);
print $parser->makepod;

πŸŽ€ Configuration πŸŽ€

*** network ***

  dns      = 192.168.7.87

+ 192.168.7.64

  netmask  = 255.255.255.192
  gateway  = 192.168.7.65

*** hosts ***

  00:50:fe:bc:65:11     192.168.7.97    plain.hades
  00:50:fe:bc:65:12     192.168.7.98    isg.ee.hades
  00:50:fe:bc:65:14     192.168.7.99    isg.ee.hades

⭐ RESULT ⭐

...and the parsed result comes out looking like this, bestie β€” no cap, every key lands exactly where the grammar said it would:

        {
          'hosts' => {
                       '00:50:fe:bc:65:11' => [
                                                '00:50:fe:bc:65:11',
                                                '192.168.7.97',
                                                'plain.hades'
                                              ],
                       '00:50:fe:bc:65:12' => [
                                                '00:50:fe:bc:65:12',
                                                '192.168.7.98',
                                                'isg.ee.hades'
                                              ],
                       '00:50:fe:bc:65:14' => [
                                                '00:50:fe:bc:65:14',
                                                '192.168.7.99',
                                                'isg.ee.hades'
                                              ]
                     },
          'network' => {
                         '192.168.7.64' => {
                                             'netmask' => '255.255.255.192',
                                             'gateway' => '192.168.7.65'
                                           },
                         'dns' => '192.168.7.87'
                       }
        };

Like, look at it πŸ’… the hosts hash is keyed by MAC and each value is that tidy little array of MAC + IP + hostname, and network is doing its own thing with 192.168.7.64 holding netmask and gateway while dns just vibes at 192.168.7.87. Structure immaculate. The grammar ate and left no crumbs ✨


🌈 SEE ALSO

  • Config::Grammar::Dynamic β€” the dynamic sibling, go say hi 🫢

Copyright (c) 2000-2005 by ETH Zurich. All rights reserved. Copyright (c) 2007 by David Schweikert. All rights reserved.

Like, all of it. Every last bit. Reserved reserved πŸ’€


πŸ“œ LICENSE

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

So yeah β€” go wild, remix it, share it, just keep it under the same terms as Perl itself, iykyk ⭐


πŸ‘‘ AUTHORS

The icon lineup, in order:

  • David Schweikert
  • Tobias Oetiker
  • Niko Tyni

Three legends, one manual page 🧚


And that's a wrap on Config::Grammar(3), bestie β€” this little beauty ships as part of perl v5.40.2, dated 2024-02-21 πŸ¦‹ go forth and parse responsibly, mwah πŸ’–

πŸ“¦ where this page comes from