GNU Info

(flex.info)Format

---

Next: Patterns Prev: Examples Up: Top

---

Enter node , (file) or (file)node

Format of the input file
************************

   The `flex' input file consists of three sections, separated by a
line with just `%%' in it:

     definitions
     %%
     rules
     %%
     user code

   The "definitions" section contains declarations of simple "name"
definitions to simplify the scanner specification, and declarations of
"start conditions", which are explained in a later section.  Name
definitions have the form:

     name definition

   The "name" is a word beginning with a letter or an underscore ('_')
followed by zero or more letters, digits, '_', or '-' (dash).  The
definition is taken to begin at the first non-white-space character
following the name and continuing to the end of the line.  The
definition can subsequently be referred to using "{name}", which will
expand to "(definition)".  For example,

     DIGIT    [0-9]
     ID       [a-z][a-z0-9]*

defines "DIGIT" to be a regular expression which matches a single
digit, and "ID" to be a regular expression which matches a letter
followed by zero-or-more letters-or-digits.  A subsequent reference to

     {DIGIT}+"."{DIGIT}*

is identical to

     ([0-9])+"."([0-9])*

and matches one-or-more digits followed by a '.' followed by
zero-or-more digits.

   The RULES section of the `flex' input contains a series of rules of
the form:

     pattern   action

where the pattern must be unindented and the action must begin on the
same line.

   Note: Patterns, for a further description of patterns and actions.

   Finally, the user code section is simply copied to `lex.yy.c'
verbatim.  It is used for companion routines which call or are called
by the scanner.  The presence of this section is optional; if it is
missing, the second `%%' in the input file may be skipped, too.

   In the definitions and rules sections, any _indented_ text or text
enclosed in `%{' and `%}' is copied verbatim to the output (with the
`%{}''s removed).  The `%{}''s must appear unindented on lines by
themselves.

   In the rules section, any indented or %{} text appearing before the
first rule may be used to declare variables which are local to the
scanning routine and (after the declarations) code which is to be
executed whenever the scanning routine is entered.  Other indented or
%{} text in the rule section is still copied to the output, but its
meaning is not well-defined and it may well cause compile-time errors
(this feature is present for `POSIX' compliance; see below for other
such features).

   In the definitions section (but not in the rules section), an
unindented comment (i.e., a line beginning with "/*") is also copied
verbatim to the output up to the next "*/".