Syntax for grammar files
A grammar file has four sections. The sections appear sequentially and are separated by %%. The sections are:
- Variables section of a grammar file
- Tokens section of a grammar file
- Rules section of a grammar file
- Structure of a configuration file record
- Add-rules section of a grammar file
- Additional flags
In addition to these sections, you may also need to define additional flags.
Variables section of a grammar file
The Variables section contains variables with initial values, which can be referenced later by rules and add-rules. Variables match structural information around data, such as brackets, separators, and spacing. For example,
VAR_L_BRACKET [
defines a variable with an initial value [ which can later be referenced by $VAR_L_BRACKET. All variables must be referenced with a $ to access their values.
Tokens section of a grammar file
The Tokens section contains patterns (tokens) used to match data such as IP addresses and user names.
Each token has a name and a regular expression. BMC Server Automation supports the Berkeley Software Distribution (BSD) extended regular expression, and BMC Server Automation has its own regular expression library, which is very close to the BSD regular expression library.
Tokens are used by rules (productions) to match lines in configuration files. For example, the following token is used to match keys in Microsoft Windows initialization (INI) files:
KEY [^][\t\n=;'"]
Note that the regular expression for the token KEY matches any string that does not contain ], [, \t, \n, =, ;, ', and ". Tokens, unlike variables, are not referenced with a preceding $.
Rules section of a grammar file
A rule has a name, tokens, actions, and arguments to actions. For each line in the input configuration file, rules are tried in sequential order of their appearance in the rules section until a match is found. The tokens in each rule are tried in order. A rule matches with a line in the configuration file if all the tokens in the rule are matched with the line. If no rule matches, the line is ignored.
You can choose to group tokens in a rule. All the tokens in a group are tried. If any tokens in the group match, the line is considered a match. Group tokens by enclosing them within square brackets [].
Rules can also refer to other rules by %rule_name so that self-referential recursive rules can be built. Rules used by other rules are called subrules. The subrules either match as a whole like regular rules or match an empty string. This is similar to "epsilon" rules in compiler terminology. Actions can appear anywhere in a rule, intermixed with tokens, and are matched and applied in the order of their occurrence. The intended result is to build a configuration file entry record for each line in the input while the matching occurs. An implicit current record is built as each line is scanned in a configuration file.
Use the following actions to build a configuration file record:
Structure of a configuration file record
The data structure of a configuration file record appears as follows. Remember this structure when writing a rule. The rule translates the configuration file entry in the file into an object with this data structure.
char *key;
char *path;
int record_num;
int rule_num;
int parent_record_num;
int is_a_leaf;
int depth;
char *prevRecKey;
struct bllist *comment_lines;
struct bllist *field_list;
char *eol_comment;
void *pPrivate;
};
Add-rules section of a grammar file
Add-rules are rules that define how an existing configuration file entry is written to a file when the entry is deployed by means of a Deploy Job or the BLCLI equivalent. Use the following rules to define how the entry is written to the configuration file.
If a BLPackage contains configuration file entries, the grammar file that was used to generate those entries is copied into the package folder. Therefore, if you apply any changes to the grammar file, you must recreate the BLPackage.
Additional flags
You can define the following flags in the variables section. To enable any of these flags, set its value to 1.
The parser is line-oriented. Each rule in the grammar is used to parse lines that match the format coded in the rule. Use these attributes to preserve configuration files with these descriptions.
The following example shows how to use KEEP_END_SLASH.
# Used to parse initialization (INI) files on Windows.
# Also used to parse /etc/X11/xdm/kdmrc and /etc/X11/gdm/gdm.conf on Linux
#
KEEP_END_SLASH 1