Format

Every configuration file is a sequence of stanzas, usually though not necessarily separated by blank lines. A stanza consists of an identifier, in the first column, followed by additional text, either on the same line, or in multiple lines. Follow-up lines must be indented, using either spaces, tabs, or the #indent preprocessor directive.

Note that a single space or tab is sufficient for establishing indentation. In programs.cfg and files.cfg, PIKT considers any whitespace following the first whitespace on a line to be part of your program or file formatting. (In all other configuration files, the extent of indentation doesn't matter.)

For example, in programs.cfg, you should do this

foobar.pl
        #!=perl
   ^
   [single tab char]

and not this

foobar.pl
        #!=perl
^^^^^^^^
   [eight space chars]

since in the second example, this would be the processed result

       #!/usr/bin/perl
^^^^^^^
   [seven space chars]

which would cause an error.

Stanza identifiers must begin with a letter, followed by an unlimited number (practically speaking) of letters, digits, hyphens (-), underscores (_), and/or periods (.). Forward slashes (/) are allowed in programs.cfg and files.cfg when specifying program identifiers. So, the following identifiers must conform to the aforementioned naming rule:

operating systems, host aliases, and host groups, in systems.cfg
defines, in defines.cfg
macros, in macros.cfg
alerts, in alerts.cfg
alarms, in alarms.cfg
object sets, in objects.cfg
program names, in programs.cfg
system file names, in files.cfg.

If you duplicate an identifier within a configuration file, this will generate an error. You may repeat the same identifier in different config domains, however. (For example, you might have a machine named "test" in systems.cfg, a define named "test" in defines.cfg, a macro named "test" in macros.cfg, and an object named "test" in an objects include file.)

If you have two (or more) different files (or programs) with the same name, you must use two (or more) different identifiers, and specify file paths either in the identifer name, else using the "path" keyword. For example, you should do this

/etc/rc.d/init.d/sshd
        ...

/etc/pam.d/sshd
        ...

or this

sshd_rc          path "/etc/rc.d/init.d/sshd" ...
        ...

sshd_pam         path "/etc/pam.d/sshd" ...
        ...

The second is the preferred method, especially for the following reason: You specify program and file identifiers without their directory at the piktc command line. In other words, this is okay

piktc -iv +P sshd_rc sshd_pam +H ...

while this is ambiguous

piktc -iv +P sshd +H ...

(You could still install both sshd's using 'piktc -iv +P all ...', however.)

The last line of every configuration file must end with a linefeed. Without the linefeed, obscure parser errors (for example, the parser silently failing without explanation) might result.

Almost without exception, and aside from the above simple rules and the Pikt language syntax rules, Pikt is indifferent to script and config file layout. In other words, spacing and line breaks really don't matter, and you may lay out your config files in any style that pleases you.

Refer to the Samples section for more examples.

1st page