Syntax for grammar files
A grammar file has four sections. The sections appear sequentially and are separated by %%
. The sections are:
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.
Note
Rules cannot contain variables. Use tokens instead.
Use the following actions to build a configuration file record:
Command | Arguments | Action |
---|---|---|
|
| Appends a new field to the |
|
| Assigns the value of one argument, |
|
| Sets the value of the |
|
| Appends the value of |
|
| Appends the value of |
|
| Pushes the value of |
|
| Pops the value of |
|
| Sets the parent key of a record to be the value of |
| None | Identifies a record as a non-leaf record. The BMC Server Automation Console uses this capability to display correct leaf and non-leaf icons. |
|
| Adds the current record to the list of configuration file records obtained from parsing the configuration file. The key of the record is set to the value of the argument |
|
| Indicates which add-rule to use to add a new configuration file record when running Deploy Job updates or the BLCLI equivalent. (See Add-rules section of a grammar file.) The |
|
| Saves comment lines in configuration file records. |
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.
struct bl_config_record {
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.
Name | Parameters | Description |
---|---|---|
|
| Writes a field, using the index at which the field is stored in the record's field list. |
|
| Writes a variable from the list in the first section of the grammar. This rule writes only variables, not tokens. |
|
| Writes all fields in a configuration file record using the argument as a delimiter between the fields. |
|
| Writes all fields in a record, starting with the index in the field list given by the first argument and using the variable argument as a delimiter between fields. |
|
| Deletes a number of additional lines given by the argument following a line that matched with a record being deleted when applying a Delete action during a Deploy Job. For example, when deleting a service from the xinetd.conf file as follows, the entry must delete two extra lines.
|
|
| Writes variables from the list using an argument as a delimiter between the fields. |
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.
Flag | Value | Description |
---|---|---|
|
| Used in XML grammars to parse XML configuration files |
|
| Used in httpd grammars to parse httpd.conf files |
|
| Used in regular grammars to preserve empty lines in a configuration file |
|
| Used in regular grammars to preserve multiple lines in a configuration file (for example, tnsnames.ora) |
|
| Used in regular grammars to preserve the leading spaces in a configuration file |
|
| Used in regular grammars that parse configuration files that contain \ in the path, such as the following format:
|
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
Comments
Log in or register to comment.