CFPEEK |
|
CFPEEK |
Sergey Poznyakoff |
This is the default input format. It is used, e.g., by GNU Dico1, GNU Mailutils2, GNU Radius3, Mailfromd4 and others.
The configuration file consists of statements and comments.
There are three classes of lexical tokens: keywords, values, and separators. Blanks, tabs, newlines and comments, collectively called white space are ignored except as they serve to separate tokens. Some white space is required to separate otherwise adjacent keywords and values.
Comments may appear anywhere where white space may appear in the configuration file. There are two kinds of comments: single-line and multi-line comments. Single-line comments start with ‘#’ or ‘//’ and continue to the end of the line:
# This is a comment // This too is a comment
Multi-line or C-style comments start with the two characters ‘/*’ (slash, star) and continue until the first occurrence of ‘*/’ (star, slash).
Multi-line comments cannot be nested. However, single-line comments may well appear within multi-line ones.
Pragmatic comments are similar to usual single-line comments, except that they cause some changes in the way the configuration is parsed. Pragmatic comments begin with a ‘#’ sign and end with the next physical newline character.
#include <file>
#include file
Include the contents of the file file. There are three possible use cases.
If file is an absolute file name, the named file is included. An error message will be issued if it does not exist.
If file contains wildcard characters (‘*’, ‘[’, ‘]’ or ‘?’), it is interpreted as shell globbing pattern and all files matching that pattern are included, in lexicographical order. If no files match the pattern, the statement is silently ignored.
Otherwise, the form with angle brackets searches for file in the include search path, while the second one looks for it in the current working directory first, and, if not found there, in the include search path. If the file is not found, an error message will be issued.
The default include search path is:
where prefix is the installation prefix.
#include_once <file>
#include_once file
Same as #include
, except that, if the file has already
been included, it will not be included again.
#line num
#line num "file"
This line causes the parser to believe, for purposes of error diagnostics, that the line number of the next source line is given by num and the current input file is named by file. If the latter is absent, the remembered file name does not change.
# num "file"
This is a special form of #line
statement, understood for
compatibility with the C preprocessor.
In fact, these statements provide a rudimentary preprocessing features. For more sophisticated ways to modify configuration before parsing, see Preprocessor.
A simple statement consists of a keyword and value separated by any amount of whitespace. Simple statement is terminated with a semicolon (‘;’).
The following is a simple statement:
standalone yes; pidfile /var/run/slb.pid;
A keyword begins with a letter and may contain letters, decimal digits, underscores (‘_’) and dashes (‘-’). Examples of keywords are: ‘expression’, ‘output-file’.
A value can be one of the following:
A number is a sequence of decimal digits.
A boolean value is one of the following: ‘yes’, ‘true’, ‘t’ or ‘1’, meaning true, and ‘no’, ‘false’, ‘nil’, ‘0’ meaning false.
An unquoted string may contain letters, digits, and any of the following characters: ‘_’, ‘-’, ‘.’, ‘/’, ‘@’, ‘*’, ‘:’.
A quoted string is any sequence of characters enclosed in double-quotes (‘"’). A backslash appearing within a quoted string introduces an escape sequence, which is replaced with a single character according to the following rules:
Sequence | Replaced with |
\a | Audible bell character (ASCII 7) |
\b | Backspace character (ASCII 8) |
\f | Form-feed character (ASCII 12) |
\n | Newline character (ASCII 10) |
\r | Carriage return character (ASCII 13) |
\t | Horizontal tabulation character (ASCII 9) |
\v | Vertical tabulation character (ASCII 11) |
\\ | A single backslash (‘\’) |
\" | A double-quote. |
In addition, the sequence ‘\newline’ is removed from the string. This allows to split long strings over several physical lines, e.g.:
"a long string may be\ split over several lines"
If the character following a backslash is not one of those specified above, the backslash is ignored and a warning is issued.
A here-document is a special construct that allows to introduce strings of text containing embedded newlines.
The <<word
construct instructs the parser to read all
the following lines up to the line containing only word, with
possible trailing blanks. Any lines thus read are concatenated
together into a single string. For example:
<<EOT A multiline string EOT
The body of a here-document is interpreted the same way as a double-quoted string, unless word is preceded by a backslash (e.g. ‘<<\EOT’) or enclosed in double-quotes, in which case the text is read as is, without interpretation of escape sequences.
If word is prefixed with -
(a dash), then all leading
tab characters are stripped from input lines and the line containing
word. Furthermore, if -
is followed by a single space,
all leading whitespace is stripped from them. This allows to indent
here-documents in a natural fashion. For example:
<<- TEXT The leading whitespace will be ignored when reading these lines. TEXT
It is important that the terminating delimiter be the only token on its line. The only exception to this rule is allowed if a here-document appears as the last element of a statement. In this case a semicolon can be placed on the same line with its terminating delimiter, as in:
help-text <<-EOT A sample help text. EOT;
A list is a comma-separated list of values. Lists are enclosed in parentheses. The following example shows a statement whose value is a list of strings:
alias (test,null);
In any case where a list is appropriate, a single value is allowed without being a member of a list: it is equivalent to a list with a single member. This means that, e.g.
alias test;
is equivalent to
alias (test);
A block statement introduces a logical group of statements. It consists of a keyword, followed by an optional value, and a sequence of statements enclosed in curly braces, as shown in the example below:
server srv1 { host 10.0.0.1; community "foo"; }
The closing curly brace may be followed by a semicolon, although this is not required.
Before actual parsing, the configuration file is preprocessed.
The built-in preprocessor handles only file inclusion
and #line
statements (see Pragmatic Comments), while the
rest of traditional preprocessing facilities, such as macro expansion,
is supported via m4
, which serves as external preprocessor.
The detailed description of m4
facilities lies far beyond
the scope of this document. You will find a complete user manual in
http://www.gnu.org/software/m4/manual.
For the rest of this subsection we assume the reader is sufficiently
acquainted with m4
macro processor.
The external preprocessor is invoked with -s flag, which instructs it to include line synchronization information in its output. This information is then used by the parser to display meaningful diagnostic.
An initial set of macro definitions is supplied by the pp-setup file, located in prefix/share/program-name/1.2/include directory.
The default pp-setup file renames all m4
built-in
macro names so they all start with the prefix ‘m4_’. This
is similar to GNU m4 --prefix-builtin option, but has an
advantage that it works with non-GNU m4
implementations as
well.
See GNU Dico in GNU Dico Manual.
See GNU Mailutils in GNU Mailutils Manual.
See GNU Radius in GNU Radius Manual.
See Mailfromd in Mailfromd Manual.
This document was generated on January 7, 2021 using makeinfo.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.