The pattern type holds regular-expression patterns, which can be used for fast text searching operations.
You create pattern constants by enclosing text within forward slashes (/). The syntax is the same as for the flex version of the lex utility. For example,
/foo|bar/specifies a pattern that matches either the text ``foo'' or the text ``bar'';
/[a-zA-Z0-9]+/matches one or more letters or digits, as will
/[[:alpha:][:digit:]]+/or
/[[:alnum:]]+/and the pattern
/^rewt.*login/matches any string with the text ``rewt'' at the beginning of a line followed somewhere later in the line by the text ``login''.
You can create disjunctions (patterns the match any of a number of
alternatives) both using the ``|
'' regular expression
operator directly, as in the first example above, or by using it
to join multiple patterns. So the first example above
could instead be written:
/foo/ | /bar/This form is convenient when constructing large disjunctions because it's easier to see what's going on.
Note that the speed of the regular expression matching does not depend on the complexity or size of the patterns, so you should feel free to make full use of the expressive power they afford.
You can assign pattern values to variables, hold them in tables, and so on. So for example you could have:
global address_filters: table[addr] of pattern = { [128.3.4.4] = /failed login/ | /access denied/, [128.3.5.1] = /access timeout/ };and then could test, for example:
if ( address_filters[c$id$orig_h] in msg ) skip_the_activity();
Note though that you cannot use create patterns dynamically. this form (or any other) to create dynamic
There are two types of pattern-matching operators: exact matching and embedded matching.
==
equality relational with one pattern operand and one
string operand (order irrelevant). For example,
"foo" == /foo|bar/yields true, while
/foo|bar/ == "foobar"yields false. The
!=
operator is the negation of the ==
operator, just as when comparing strings or numerics.
Note that for exact matching, the ^
(anchor to beginning-of-line)
and $
(anchor to end-of-line) regular expression operators are
redundant: since the match is exact, every pattern is implicitly
anchored to the beginning and end of the line.
Embedded matching tests whether a given pattern appears anywhere within a given string. You specify embedded pattern matching using the in operator. It takes two operands, the first (which must appear on the left-hand side) of type pattern, the second of type string. For example,
/foo|bar/ in "foobar"yields true, as does
/oob/ in "foobar"but
/^oob/ in "foobar"does not, since the text ``oob'' does not appear the beginning of the string ``foobar''. Note, though, that the $ regular expression operator (anchor to end-of-line) is not currently supported, so:
/oob$/ in "foobar"currently yields true. This is likely to change in the future.
Finally, the !in operator yields the negation of the in operator.