Starting version 8.9.03, BMC Server Automation is renamed to TrueSight Server Automation. This space contains information about BMC Server Automation 8.9.02 and previous versions. For TrueSight Server Automation 8.9.03 and later releases, see TrueSight Server Automation 8.9.

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,


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.


Rules cannot contain variables. Use tokens instead.

Use the following actions to build a configuration file record:






Appends a new field to the field_list in the record.

The argument to $new_field is a number that is an index (0-based) to the token position in the rule. Variables and arguments are not counted as tokens. For example, in the following rule, the argument to $new_field is $3, which refers to the string matched by the token HKEY.

begin_tag WS LT WS HKEY WS new_field $3


$var_name $arg

Assigns the value of one argument, $arg, to another argument, $var_name.

$arg can either be a $var_name or a $number argument.



Sets the value of the $var_name variable to empty.


$var_name $arg

Appends the value of $arg to the $var_name variable using / as the delimiter. Use this action to build a full key representing a record in a hierarchy. Each $append_to_var action adds a new level to the hierarchy.


$var_name $arg

Appends the value of $arg to the $var_name variable using - as the delimiter. Use this action to build keys of records that are at the same level — that is, the fields in the key differentiate two records at the same level.



Pushes the value of $var_name on the stack. Use this action to keep track of parent keys at any level in a hierarchy of records.



Pops the value of $var_name on the stack. Use this action to keep track of parent keys at any level in a hierarchy of records.



Sets the parent key of a record to be the value of $var_name in a hierarchy of records.



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 $arg. After a record is saved, any $new_field commands run in a rule are posted against a new record.



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 $number argument is the add-rule number, assuming that add-rules are numbered from 0. Each rule used to parse a record should have a corresponding add-rule to add new records. All the configuration file records created using a parsing rule are added by the corresponding add-rule when you run a Deploy Job or the BLCLI equivalent.



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.






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.


$number $var_name

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.

Service login


$var_name $var_name

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.






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
Was this page helpful? Yes No Submitting... Thank you