forked from Mirrors/freeswitch
9da5d7e90f
git-svn-id: http://svn.freeswitch.org/svn/freeswitch/trunk@3732 d0543943-73ff-0310-b7d9-9358b9ac24b2
1646 lines
67 KiB
Groff
1646 lines
67 KiB
Groff
.TH PCREPATTERN 3
|
|
.SH NAME
|
|
PCRE - Perl-compatible regular expressions
|
|
.SH "PCRE REGULAR EXPRESSION DETAILS"
|
|
.rs
|
|
.sp
|
|
The syntax and semantics of the regular expressions supported by PCRE are
|
|
described below. Regular expressions are also described in the Perl
|
|
documentation and in a number of books, some of which have copious examples.
|
|
Jeffrey Friedl's "Mastering Regular Expressions", published by O'Reilly, covers
|
|
regular expressions in great detail. This description of PCRE's regular
|
|
expressions is intended as reference material.
|
|
.P
|
|
The original operation of PCRE was on strings of one-byte characters. However,
|
|
there is now also support for UTF-8 character strings. To use this, you must
|
|
build PCRE to include UTF-8 support, and then call \fBpcre_compile()\fP with
|
|
the PCRE_UTF8 option. How this affects pattern matching is mentioned in several
|
|
places below. There is also a summary of UTF-8 features in the
|
|
.\" HTML <a href="pcre.html#utf8support">
|
|
.\" </a>
|
|
section on UTF-8 support
|
|
.\"
|
|
in the main
|
|
.\" HREF
|
|
\fBpcre\fP
|
|
.\"
|
|
page.
|
|
.P
|
|
The remainder of this document discusses the patterns that are supported by
|
|
PCRE when its main matching function, \fBpcre_exec()\fP, is used.
|
|
From release 6.0, PCRE offers a second matching function,
|
|
\fBpcre_dfa_exec()\fP, which matches using a different algorithm that is not
|
|
Perl-compatible. The advantages and disadvantages of the alternative function,
|
|
and how it differs from the normal function, are discussed in the
|
|
.\" HREF
|
|
\fBpcrematching\fP
|
|
.\"
|
|
page.
|
|
.P
|
|
A regular expression is a pattern that is matched against a subject string from
|
|
left to right. Most characters stand for themselves in a pattern, and match the
|
|
corresponding characters in the subject. As a trivial example, the pattern
|
|
.sp
|
|
The quick brown fox
|
|
.sp
|
|
matches a portion of a subject string that is identical to itself. When
|
|
caseless matching is specified (the PCRE_CASELESS option), letters are matched
|
|
independently of case. In UTF-8 mode, PCRE always understands the concept of
|
|
case for characters whose values are less than 128, so caseless matching is
|
|
always possible. For characters with higher values, the concept of case is
|
|
supported if PCRE is compiled with Unicode property support, but not otherwise.
|
|
If you want to use caseless matching for characters 128 and above, you must
|
|
ensure that PCRE is compiled with Unicode property support as well as with
|
|
UTF-8 support.
|
|
.P
|
|
The power of regular expressions comes from the ability to include alternatives
|
|
and repetitions in the pattern. These are encoded in the pattern by the use of
|
|
\fImetacharacters\fP, which do not stand for themselves but instead are
|
|
interpreted in some special way.
|
|
.P
|
|
There are two different sets of metacharacters: those that are recognized
|
|
anywhere in the pattern except within square brackets, and those that are
|
|
recognized in square brackets. Outside square brackets, the metacharacters are
|
|
as follows:
|
|
.sp
|
|
\e general escape character with several uses
|
|
^ assert start of string (or line, in multiline mode)
|
|
$ assert end of string (or line, in multiline mode)
|
|
. match any character except newline (by default)
|
|
[ start character class definition
|
|
| start of alternative branch
|
|
( start subpattern
|
|
) end subpattern
|
|
? extends the meaning of (
|
|
also 0 or 1 quantifier
|
|
also quantifier minimizer
|
|
* 0 or more quantifier
|
|
+ 1 or more quantifier
|
|
also "possessive quantifier"
|
|
{ start min/max quantifier
|
|
.sp
|
|
Part of a pattern that is in square brackets is called a "character class". In
|
|
a character class the only metacharacters are:
|
|
.sp
|
|
\e general escape character
|
|
^ negate the class, but only if the first character
|
|
- indicates character range
|
|
.\" JOIN
|
|
[ POSIX character class (only if followed by POSIX
|
|
syntax)
|
|
] terminates the character class
|
|
.sp
|
|
The following sections describe the use of each of the metacharacters.
|
|
.
|
|
.SH BACKSLASH
|
|
.rs
|
|
.sp
|
|
The backslash character has several uses. Firstly, if it is followed by a
|
|
non-alphanumeric character, it takes away any special meaning that character
|
|
may have. This use of backslash as an escape character applies both inside and
|
|
outside character classes.
|
|
.P
|
|
For example, if you want to match a * character, you write \e* in the pattern.
|
|
This escaping action applies whether or not the following character would
|
|
otherwise be interpreted as a metacharacter, so it is always safe to precede a
|
|
non-alphanumeric with backslash to specify that it stands for itself. In
|
|
particular, if you want to match a backslash, you write \e\e.
|
|
.P
|
|
If a pattern is compiled with the PCRE_EXTENDED option, whitespace in the
|
|
pattern (other than in a character class) and characters between a # outside
|
|
a character class and the next newline are ignored. An escaping backslash can
|
|
be used to include a whitespace or # character as part of the pattern.
|
|
.P
|
|
If you want to remove the special meaning from a sequence of characters, you
|
|
can do so by putting them between \eQ and \eE. This is different from Perl in
|
|
that $ and @ are handled as literals in \eQ...\eE sequences in PCRE, whereas in
|
|
Perl, $ and @ cause variable interpolation. Note the following examples:
|
|
.sp
|
|
Pattern PCRE matches Perl matches
|
|
.sp
|
|
.\" JOIN
|
|
\eQabc$xyz\eE abc$xyz abc followed by the
|
|
contents of $xyz
|
|
\eQabc\e$xyz\eE abc\e$xyz abc\e$xyz
|
|
\eQabc\eE\e$\eQxyz\eE abc$xyz abc$xyz
|
|
.sp
|
|
The \eQ...\eE sequence is recognized both inside and outside character classes.
|
|
.
|
|
.
|
|
.\" HTML <a name="digitsafterbackslash"></a>
|
|
.SS "Non-printing characters"
|
|
.rs
|
|
.sp
|
|
A second use of backslash provides a way of encoding non-printing characters
|
|
in patterns in a visible manner. There is no restriction on the appearance of
|
|
non-printing characters, apart from the binary zero that terminates a pattern,
|
|
but when a pattern is being prepared by text editing, it is usually easier to
|
|
use one of the following escape sequences than the binary character it
|
|
represents:
|
|
.sp
|
|
\ea alarm, that is, the BEL character (hex 07)
|
|
\ecx "control-x", where x is any character
|
|
\ee escape (hex 1B)
|
|
\ef formfeed (hex 0C)
|
|
\en newline (hex 0A)
|
|
\er carriage return (hex 0D)
|
|
\et tab (hex 09)
|
|
\eddd character with octal code ddd, or backreference
|
|
\exhh character with hex code hh
|
|
\ex{hhh..} character with hex code hhh..
|
|
.sp
|
|
The precise effect of \ecx is as follows: if x is a lower case letter, it
|
|
is converted to upper case. Then bit 6 of the character (hex 40) is inverted.
|
|
Thus \ecz becomes hex 1A, but \ec{ becomes hex 3B, while \ec; becomes hex
|
|
7B.
|
|
.P
|
|
After \ex, from zero to two hexadecimal digits are read (letters can be in
|
|
upper or lower case). Any number of hexadecimal digits may appear between \ex{
|
|
and }, but the value of the character code must be less than 256 in non-UTF-8
|
|
mode, and less than 2**31 in UTF-8 mode (that is, the maximum hexadecimal value
|
|
is 7FFFFFFF). If characters other than hexadecimal digits appear between \ex{
|
|
and }, or if there is no terminating }, this form of escape is not recognized.
|
|
Instead, the initial \ex will be interpreted as a basic hexadecimal escape,
|
|
with no following digits, giving a character whose value is zero.
|
|
.P
|
|
Characters whose value is less than 256 can be defined by either of the two
|
|
syntaxes for \ex. There is no difference in the way they are handled. For
|
|
example, \exdc is exactly the same as \ex{dc}.
|
|
.P
|
|
After \e0 up to two further octal digits are read. If there are fewer than two
|
|
digits, just those that are present are used. Thus the sequence \e0\ex\e07
|
|
specifies two binary zeros followed by a BEL character (code value 7). Make
|
|
sure you supply two digits after the initial zero if the pattern character that
|
|
follows is itself an octal digit.
|
|
.P
|
|
The handling of a backslash followed by a digit other than 0 is complicated.
|
|
Outside a character class, PCRE reads it and any following digits as a decimal
|
|
number. If the number is less than 10, or if there have been at least that many
|
|
previous capturing left parentheses in the expression, the entire sequence is
|
|
taken as a \fIback reference\fP. A description of how this works is given
|
|
.\" HTML <a href="#backreferences">
|
|
.\" </a>
|
|
later,
|
|
.\"
|
|
following the discussion of
|
|
.\" HTML <a href="#subpattern">
|
|
.\" </a>
|
|
parenthesized subpatterns.
|
|
.\"
|
|
.P
|
|
Inside a character class, or if the decimal number is greater than 9 and there
|
|
have not been that many capturing subpatterns, PCRE re-reads up to three octal
|
|
digits following the backslash, ane uses them to generate a data character. Any
|
|
subsequent digits stand for themselves. In non-UTF-8 mode, the value of a
|
|
character specified in octal must be less than \e400. In UTF-8 mode, values up
|
|
to \e777 are permitted. For example:
|
|
.sp
|
|
\e040 is another way of writing a space
|
|
.\" JOIN
|
|
\e40 is the same, provided there are fewer than 40
|
|
previous capturing subpatterns
|
|
\e7 is always a back reference
|
|
.\" JOIN
|
|
\e11 might be a back reference, or another way of
|
|
writing a tab
|
|
\e011 is always a tab
|
|
\e0113 is a tab followed by the character "3"
|
|
.\" JOIN
|
|
\e113 might be a back reference, otherwise the
|
|
character with octal code 113
|
|
.\" JOIN
|
|
\e377 might be a back reference, otherwise
|
|
the byte consisting entirely of 1 bits
|
|
.\" JOIN
|
|
\e81 is either a back reference, or a binary zero
|
|
followed by the two characters "8" and "1"
|
|
.sp
|
|
Note that octal values of 100 or greater must not be introduced by a leading
|
|
zero, because no more than three octal digits are ever read.
|
|
.P
|
|
All the sequences that define a single character value can be used both inside
|
|
and outside character classes. In addition, inside a character class, the
|
|
sequence \eb is interpreted as the backspace character (hex 08), and the
|
|
sequence \eX is interpreted as the character "X". Outside a character class,
|
|
these sequences have different meanings
|
|
.\" HTML <a href="#uniextseq">
|
|
.\" </a>
|
|
(see below).
|
|
.\"
|
|
.
|
|
.
|
|
.SS "Generic character types"
|
|
.rs
|
|
.sp
|
|
The third use of backslash is for specifying generic character types. The
|
|
following are always recognized:
|
|
.sp
|
|
\ed any decimal digit
|
|
\eD any character that is not a decimal digit
|
|
\es any whitespace character
|
|
\eS any character that is not a whitespace character
|
|
\ew any "word" character
|
|
\eW any "non-word" character
|
|
.sp
|
|
Each pair of escape sequences partitions the complete set of characters into
|
|
two disjoint sets. Any given character matches one, and only one, of each pair.
|
|
.P
|
|
These character type sequences can appear both inside and outside character
|
|
classes. They each match one character of the appropriate type. If the current
|
|
matching point is at the end of the subject string, all of them fail, since
|
|
there is no character to match.
|
|
.P
|
|
For compatibility with Perl, \es does not match the VT character (code 11).
|
|
This makes it different from the the POSIX "space" class. The \es characters
|
|
are HT (9), LF (10), FF (12), CR (13), and space (32). (If "use locale;" is
|
|
included in a Perl script, \es may match the VT character. In PCRE, it never
|
|
does.)
|
|
.P
|
|
A "word" character is an underscore or any character less than 256 that is a
|
|
letter or digit. The definition of letters and digits is controlled by PCRE's
|
|
low-valued character tables, and may vary if locale-specific matching is taking
|
|
place (see
|
|
.\" HTML <a href="pcreapi.html#localesupport">
|
|
.\" </a>
|
|
"Locale support"
|
|
.\"
|
|
in the
|
|
.\" HREF
|
|
\fBpcreapi\fP
|
|
.\"
|
|
page). For example, in the "fr_FR" (French) locale, some character codes
|
|
greater than 128 are used for accented letters, and these are matched by \ew.
|
|
.P
|
|
In UTF-8 mode, characters with values greater than 128 never match \ed, \es, or
|
|
\ew, and always match \eD, \eS, and \eW. This is true even when Unicode
|
|
character property support is available. The use of locales with Unicode is
|
|
discouraged.
|
|
.
|
|
.
|
|
.\" HTML <a name="uniextseq"></a>
|
|
.SS Unicode character properties
|
|
.rs
|
|
.sp
|
|
When PCRE is built with Unicode character property support, three additional
|
|
escape sequences to match character properties are available when UTF-8 mode
|
|
is selected. They are:
|
|
.sp
|
|
\ep{\fIxx\fP} a character with the \fIxx\fP property
|
|
\eP{\fIxx\fP} a character without the \fIxx\fP property
|
|
\eX an extended Unicode sequence
|
|
.sp
|
|
The property names represented by \fIxx\fP above are limited to the Unicode
|
|
script names, the general category properties, and "Any", which matches any
|
|
character (including newline). Other properties such as "InMusicalSymbols" are
|
|
not currently supported by PCRE. Note that \eP{Any} does not match any
|
|
characters, so always causes a match failure.
|
|
.P
|
|
Sets of Unicode characters are defined as belonging to certain scripts. A
|
|
character from one of these sets can be matched using a script name. For
|
|
example:
|
|
.sp
|
|
\ep{Greek}
|
|
\eP{Han}
|
|
.sp
|
|
Those that are not part of an identified script are lumped together as
|
|
"Common". The current list of scripts is:
|
|
.P
|
|
Arabic,
|
|
Armenian,
|
|
Bengali,
|
|
Bopomofo,
|
|
Braille,
|
|
Buginese,
|
|
Buhid,
|
|
Canadian_Aboriginal,
|
|
Cherokee,
|
|
Common,
|
|
Coptic,
|
|
Cypriot,
|
|
Cyrillic,
|
|
Deseret,
|
|
Devanagari,
|
|
Ethiopic,
|
|
Georgian,
|
|
Glagolitic,
|
|
Gothic,
|
|
Greek,
|
|
Gujarati,
|
|
Gurmukhi,
|
|
Han,
|
|
Hangul,
|
|
Hanunoo,
|
|
Hebrew,
|
|
Hiragana,
|
|
Inherited,
|
|
Kannada,
|
|
Katakana,
|
|
Kharoshthi,
|
|
Khmer,
|
|
Lao,
|
|
Latin,
|
|
Limbu,
|
|
Linear_B,
|
|
Malayalam,
|
|
Mongolian,
|
|
Myanmar,
|
|
New_Tai_Lue,
|
|
Ogham,
|
|
Old_Italic,
|
|
Old_Persian,
|
|
Oriya,
|
|
Osmanya,
|
|
Runic,
|
|
Shavian,
|
|
Sinhala,
|
|
Syloti_Nagri,
|
|
Syriac,
|
|
Tagalog,
|
|
Tagbanwa,
|
|
Tai_Le,
|
|
Tamil,
|
|
Telugu,
|
|
Thaana,
|
|
Thai,
|
|
Tibetan,
|
|
Tifinagh,
|
|
Ugaritic,
|
|
Yi.
|
|
.P
|
|
Each character has exactly one general category property, specified by a
|
|
two-letter abbreviation. For compatibility with Perl, negation can be specified
|
|
by including a circumflex between the opening brace and the property name. For
|
|
example, \ep{^Lu} is the same as \eP{Lu}.
|
|
.P
|
|
If only one letter is specified with \ep or \eP, it includes all the general
|
|
category properties that start with that letter. In this case, in the absence
|
|
of negation, the curly brackets in the escape sequence are optional; these two
|
|
examples have the same effect:
|
|
.sp
|
|
\ep{L}
|
|
\epL
|
|
.sp
|
|
The following general category property codes are supported:
|
|
.sp
|
|
C Other
|
|
Cc Control
|
|
Cf Format
|
|
Cn Unassigned
|
|
Co Private use
|
|
Cs Surrogate
|
|
.sp
|
|
L Letter
|
|
Ll Lower case letter
|
|
Lm Modifier letter
|
|
Lo Other letter
|
|
Lt Title case letter
|
|
Lu Upper case letter
|
|
.sp
|
|
M Mark
|
|
Mc Spacing mark
|
|
Me Enclosing mark
|
|
Mn Non-spacing mark
|
|
.sp
|
|
N Number
|
|
Nd Decimal number
|
|
Nl Letter number
|
|
No Other number
|
|
.sp
|
|
P Punctuation
|
|
Pc Connector punctuation
|
|
Pd Dash punctuation
|
|
Pe Close punctuation
|
|
Pf Final punctuation
|
|
Pi Initial punctuation
|
|
Po Other punctuation
|
|
Ps Open punctuation
|
|
.sp
|
|
S Symbol
|
|
Sc Currency symbol
|
|
Sk Modifier symbol
|
|
Sm Mathematical symbol
|
|
So Other symbol
|
|
.sp
|
|
Z Separator
|
|
Zl Line separator
|
|
Zp Paragraph separator
|
|
Zs Space separator
|
|
.sp
|
|
The special property L& is also supported: it matches a character that has
|
|
the Lu, Ll, or Lt property, in other words, a letter that is not classified as
|
|
a modifier or "other".
|
|
.P
|
|
The long synonyms for these properties that Perl supports (such as \ep{Letter})
|
|
are not supported by PCRE, nor is it permitted to prefix any of these
|
|
properties with "Is".
|
|
.P
|
|
No character that is in the Unicode table has the Cn (unassigned) property.
|
|
Instead, this property is assumed for any code point that is not in the
|
|
Unicode table.
|
|
.P
|
|
Specifying caseless matching does not affect these escape sequences. For
|
|
example, \ep{Lu} always matches only upper case letters.
|
|
.P
|
|
The \eX escape matches any number of Unicode characters that form an extended
|
|
Unicode sequence. \eX is equivalent to
|
|
.sp
|
|
(?>\ePM\epM*)
|
|
.sp
|
|
That is, it matches a character without the "mark" property, followed by zero
|
|
or more characters with the "mark" property, and treats the sequence as an
|
|
atomic group
|
|
.\" HTML <a href="#atomicgroup">
|
|
.\" </a>
|
|
(see below).
|
|
.\"
|
|
Characters with the "mark" property are typically accents that affect the
|
|
preceding character.
|
|
.P
|
|
Matching characters by Unicode property is not fast, because PCRE has to search
|
|
a structure that contains data for over fifteen thousand characters. That is
|
|
why the traditional escape sequences such as \ed and \ew do not use Unicode
|
|
properties in PCRE.
|
|
.
|
|
.
|
|
.\" HTML <a name="smallassertions"></a>
|
|
.SS "Simple assertions"
|
|
.rs
|
|
.sp
|
|
The fourth use of backslash is for certain simple assertions. An assertion
|
|
specifies a condition that has to be met at a particular point in a match,
|
|
without consuming any characters from the subject string. The use of
|
|
subpatterns for more complicated assertions is described
|
|
.\" HTML <a href="#bigassertions">
|
|
.\" </a>
|
|
below.
|
|
.\"
|
|
The backslashed assertions are:
|
|
.sp
|
|
\eb matches at a word boundary
|
|
\eB matches when not at a word boundary
|
|
\eA matches at start of subject
|
|
\eZ matches at end of subject or before newline at end
|
|
\ez matches at end of subject
|
|
\eG matches at first matching position in subject
|
|
.sp
|
|
These assertions may not appear in character classes (but note that \eb has a
|
|
different meaning, namely the backspace character, inside a character class).
|
|
.P
|
|
A word boundary is a position in the subject string where the current character
|
|
and the previous character do not both match \ew or \eW (i.e. one matches
|
|
\ew and the other matches \eW), or the start or end of the string if the
|
|
first or last character matches \ew, respectively.
|
|
.P
|
|
The \eA, \eZ, and \ez assertions differ from the traditional circumflex and
|
|
dollar (described in the next section) in that they only ever match at the very
|
|
start and end of the subject string, whatever options are set. Thus, they are
|
|
independent of multiline mode. These three assertions are not affected by the
|
|
PCRE_NOTBOL or PCRE_NOTEOL options, which affect only the behaviour of the
|
|
circumflex and dollar metacharacters. However, if the \fIstartoffset\fP
|
|
argument of \fBpcre_exec()\fP is non-zero, indicating that matching is to start
|
|
at a point other than the beginning of the subject, \eA can never match. The
|
|
difference between \eZ and \ez is that \eZ matches before a newline at the end
|
|
of the string as well as at the very end, whereas \ez matches only at the end.
|
|
.P
|
|
The \eG assertion is true only when the current matching position is at the
|
|
start point of the match, as specified by the \fIstartoffset\fP argument of
|
|
\fBpcre_exec()\fP. It differs from \eA when the value of \fIstartoffset\fP is
|
|
non-zero. By calling \fBpcre_exec()\fP multiple times with appropriate
|
|
arguments, you can mimic Perl's /g option, and it is in this kind of
|
|
implementation where \eG can be useful.
|
|
.P
|
|
Note, however, that PCRE's interpretation of \eG, as the start of the current
|
|
match, is subtly different from Perl's, which defines it as the end of the
|
|
previous match. In Perl, these can be different when the previously matched
|
|
string was empty. Because PCRE does just one match at a time, it cannot
|
|
reproduce this behaviour.
|
|
.P
|
|
If all the alternatives of a pattern begin with \eG, the expression is anchored
|
|
to the starting match position, and the "anchored" flag is set in the compiled
|
|
regular expression.
|
|
.
|
|
.
|
|
.SH "CIRCUMFLEX AND DOLLAR"
|
|
.rs
|
|
.sp
|
|
Outside a character class, in the default matching mode, the circumflex
|
|
character is an assertion that is true only if the current matching point is
|
|
at the start of the subject string. If the \fIstartoffset\fP argument of
|
|
\fBpcre_exec()\fP is non-zero, circumflex can never match if the PCRE_MULTILINE
|
|
option is unset. Inside a character class, circumflex has an entirely different
|
|
meaning
|
|
.\" HTML <a href="#characterclass">
|
|
.\" </a>
|
|
(see below).
|
|
.\"
|
|
.P
|
|
Circumflex need not be the first character of the pattern if a number of
|
|
alternatives are involved, but it should be the first thing in each alternative
|
|
in which it appears if the pattern is ever to match that branch. If all
|
|
possible alternatives start with a circumflex, that is, if the pattern is
|
|
constrained to match only at the start of the subject, it is said to be an
|
|
"anchored" pattern. (There are also other constructs that can cause a pattern
|
|
to be anchored.)
|
|
.P
|
|
A dollar character is an assertion that is true only if the current matching
|
|
point is at the end of the subject string, or immediately before a newline
|
|
at the end of the string (by default). Dollar need not be the last character of
|
|
the pattern if a number of alternatives are involved, but it should be the last
|
|
item in any branch in which it appears. Dollar has no special meaning in a
|
|
character class.
|
|
.P
|
|
The meaning of dollar can be changed so that it matches only at the very end of
|
|
the string, by setting the PCRE_DOLLAR_ENDONLY option at compile time. This
|
|
does not affect the \eZ assertion.
|
|
.P
|
|
The meanings of the circumflex and dollar characters are changed if the
|
|
PCRE_MULTILINE option is set. When this is the case, a circumflex matches
|
|
immediately after internal newlines as well as at the start of the subject
|
|
string. It does not match after a newline that ends the string. A dollar
|
|
matches before any newlines in the string, as well as at the very end, when
|
|
PCRE_MULTILINE is set. When newline is specified as the two-character
|
|
sequence CRLF, isolated CR and LF characters do not indicate newlines.
|
|
.P
|
|
For example, the pattern /^abc$/ matches the subject string "def\enabc" (where
|
|
\en represents a newline) in multiline mode, but not otherwise. Consequently,
|
|
patterns that are anchored in single line mode because all branches start with
|
|
^ are not anchored in multiline mode, and a match for circumflex is possible
|
|
when the \fIstartoffset\fP argument of \fBpcre_exec()\fP is non-zero. The
|
|
PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is set.
|
|
.P
|
|
Note that the sequences \eA, \eZ, and \ez can be used to match the start and
|
|
end of the subject in both modes, and if all branches of a pattern start with
|
|
\eA it is always anchored, whether or not PCRE_MULTILINE is set.
|
|
.
|
|
.
|
|
.SH "FULL STOP (PERIOD, DOT)"
|
|
.rs
|
|
.sp
|
|
Outside a character class, a dot in the pattern matches any one character in
|
|
the subject string except (by default) a character that signifies the end of a
|
|
line. In UTF-8 mode, the matched character may be more than one byte long. When
|
|
a line ending is defined as a single character (CR or LF), dot never matches
|
|
that character; when the two-character sequence CRLF is used, dot does not
|
|
match CR if it is immediately followed by LF, but otherwise it matches all
|
|
characters (including isolated CRs and LFs).
|
|
.P
|
|
The behaviour of dot with regard to newlines can be changed. If the PCRE_DOTALL
|
|
option is set, a dot matches any one character, without exception. If newline
|
|
is defined as the two-character sequence CRLF, it takes two dots to match it.
|
|
.P
|
|
The handling of dot is entirely independent of the handling of circumflex and
|
|
dollar, the only relationship being that they both involve newlines. Dot has no
|
|
special meaning in a character class.
|
|
.
|
|
.
|
|
.SH "MATCHING A SINGLE BYTE"
|
|
.rs
|
|
.sp
|
|
Outside a character class, the escape sequence \eC matches any one byte, both
|
|
in and out of UTF-8 mode. Unlike a dot, it always matches CR and LF. The
|
|
feature is provided in Perl in order to match individual bytes in UTF-8 mode.
|
|
Because it breaks up UTF-8 characters into individual bytes, what remains in
|
|
the string may be a malformed UTF-8 string. For this reason, the \eC escape
|
|
sequence is best avoided.
|
|
.P
|
|
PCRE does not allow \eC to appear in lookbehind assertions
|
|
.\" HTML <a href="#lookbehind">
|
|
.\" </a>
|
|
(described below),
|
|
.\"
|
|
because in UTF-8 mode this would make it impossible to calculate the length of
|
|
the lookbehind.
|
|
.
|
|
.
|
|
.\" HTML <a name="characterclass"></a>
|
|
.SH "SQUARE BRACKETS AND CHARACTER CLASSES"
|
|
.rs
|
|
.sp
|
|
An opening square bracket introduces a character class, terminated by a closing
|
|
square bracket. A closing square bracket on its own is not special. If a
|
|
closing square bracket is required as a member of the class, it should be the
|
|
first data character in the class (after an initial circumflex, if present) or
|
|
escaped with a backslash.
|
|
.P
|
|
A character class matches a single character in the subject. In UTF-8 mode, the
|
|
character may occupy more than one byte. A matched character must be in the set
|
|
of characters defined by the class, unless the first character in the class
|
|
definition is a circumflex, in which case the subject character must not be in
|
|
the set defined by the class. If a circumflex is actually required as a member
|
|
of the class, ensure it is not the first character, or escape it with a
|
|
backslash.
|
|
.P
|
|
For example, the character class [aeiou] matches any lower case vowel, while
|
|
[^aeiou] matches any character that is not a lower case vowel. Note that a
|
|
circumflex is just a convenient notation for specifying the characters that
|
|
are in the class by enumerating those that are not. A class that starts with a
|
|
circumflex is not an assertion: it still consumes a character from the subject
|
|
string, and therefore it fails if the current pointer is at the end of the
|
|
string.
|
|
.P
|
|
In UTF-8 mode, characters with values greater than 255 can be included in a
|
|
class as a literal string of bytes, or by using the \ex{ escaping mechanism.
|
|
.P
|
|
When caseless matching is set, any letters in a class represent both their
|
|
upper case and lower case versions, so for example, a caseless [aeiou] matches
|
|
"A" as well as "a", and a caseless [^aeiou] does not match "A", whereas a
|
|
caseful version would. In UTF-8 mode, PCRE always understands the concept of
|
|
case for characters whose values are less than 128, so caseless matching is
|
|
always possible. For characters with higher values, the concept of case is
|
|
supported if PCRE is compiled with Unicode property support, but not otherwise.
|
|
If you want to use caseless matching for characters 128 and above, you must
|
|
ensure that PCRE is compiled with Unicode property support as well as with
|
|
UTF-8 support.
|
|
.P
|
|
Characters that might indicate line breaks (CR and LF) are never treated in any
|
|
special way when matching character classes, whatever line-ending sequence is
|
|
in use, and whatever setting of the PCRE_DOTALL and PCRE_MULTILINE options is
|
|
used. A class such as [^a] always matches one of these characters.
|
|
.P
|
|
The minus (hyphen) character can be used to specify a range of characters in a
|
|
character class. For example, [d-m] matches any letter between d and m,
|
|
inclusive. If a minus character is required in a class, it must be escaped with
|
|
a backslash or appear in a position where it cannot be interpreted as
|
|
indicating a range, typically as the first or last character in the class.
|
|
.P
|
|
It is not possible to have the literal character "]" as the end character of a
|
|
range. A pattern such as [W-]46] is interpreted as a class of two characters
|
|
("W" and "-") followed by a literal string "46]", so it would match "W46]" or
|
|
"-46]". However, if the "]" is escaped with a backslash it is interpreted as
|
|
the end of range, so [W-\e]46] is interpreted as a class containing a range
|
|
followed by two other characters. The octal or hexadecimal representation of
|
|
"]" can also be used to end a range.
|
|
.P
|
|
Ranges operate in the collating sequence of character values. They can also be
|
|
used for characters specified numerically, for example [\e000-\e037]. In UTF-8
|
|
mode, ranges can include characters whose values are greater than 255, for
|
|
example [\ex{100}-\ex{2ff}].
|
|
.P
|
|
If a range that includes letters is used when caseless matching is set, it
|
|
matches the letters in either case. For example, [W-c] is equivalent to
|
|
[][\e\e^_`wxyzabc], matched caselessly, and in non-UTF-8 mode, if character
|
|
tables for the "fr_FR" locale are in use, [\exc8-\excb] matches accented E
|
|
characters in both cases. In UTF-8 mode, PCRE supports the concept of case for
|
|
characters with values greater than 128 only when it is compiled with Unicode
|
|
property support.
|
|
.P
|
|
The character types \ed, \eD, \ep, \eP, \es, \eS, \ew, and \eW may also appear
|
|
in a character class, and add the characters that they match to the class. For
|
|
example, [\edABCDEF] matches any hexadecimal digit. A circumflex can
|
|
conveniently be used with the upper case character types to specify a more
|
|
restricted set of characters than the matching lower case type. For example,
|
|
the class [^\eW_] matches any letter or digit, but not underscore.
|
|
.P
|
|
The only metacharacters that are recognized in character classes are backslash,
|
|
hyphen (only where it can be interpreted as specifying a range), circumflex
|
|
(only at the start), opening square bracket (only when it can be interpreted as
|
|
introducing a POSIX class name - see the next section), and the terminating
|
|
closing square bracket. However, escaping other non-alphanumeric characters
|
|
does no harm.
|
|
.
|
|
.
|
|
.SH "POSIX CHARACTER CLASSES"
|
|
.rs
|
|
.sp
|
|
Perl supports the POSIX notation for character classes. This uses names
|
|
enclosed by [: and :] within the enclosing square brackets. PCRE also supports
|
|
this notation. For example,
|
|
.sp
|
|
[01[:alpha:]%]
|
|
.sp
|
|
matches "0", "1", any alphabetic character, or "%". The supported class names
|
|
are
|
|
.sp
|
|
alnum letters and digits
|
|
alpha letters
|
|
ascii character codes 0 - 127
|
|
blank space or tab only
|
|
cntrl control characters
|
|
digit decimal digits (same as \ed)
|
|
graph printing characters, excluding space
|
|
lower lower case letters
|
|
print printing characters, including space
|
|
punct printing characters, excluding letters and digits
|
|
space white space (not quite the same as \es)
|
|
upper upper case letters
|
|
word "word" characters (same as \ew)
|
|
xdigit hexadecimal digits
|
|
.sp
|
|
The "space" characters are HT (9), LF (10), VT (11), FF (12), CR (13), and
|
|
space (32). Notice that this list includes the VT character (code 11). This
|
|
makes "space" different to \es, which does not include VT (for Perl
|
|
compatibility).
|
|
.P
|
|
The name "word" is a Perl extension, and "blank" is a GNU extension from Perl
|
|
5.8. Another Perl extension is negation, which is indicated by a ^ character
|
|
after the colon. For example,
|
|
.sp
|
|
[12[:^digit:]]
|
|
.sp
|
|
matches "1", "2", or any non-digit. PCRE (and Perl) also recognize the POSIX
|
|
syntax [.ch.] and [=ch=] where "ch" is a "collating element", but these are not
|
|
supported, and an error is given if they are encountered.
|
|
.P
|
|
In UTF-8 mode, characters with values greater than 128 do not match any of
|
|
the POSIX character classes.
|
|
.
|
|
.
|
|
.SH "VERTICAL BAR"
|
|
.rs
|
|
.sp
|
|
Vertical bar characters are used to separate alternative patterns. For example,
|
|
the pattern
|
|
.sp
|
|
gilbert|sullivan
|
|
.sp
|
|
matches either "gilbert" or "sullivan". Any number of alternatives may appear,
|
|
and an empty alternative is permitted (matching the empty string). The matching
|
|
process tries each alternative in turn, from left to right, and the first one
|
|
that succeeds is used. If the alternatives are within a subpattern
|
|
.\" HTML <a href="#subpattern">
|
|
.\" </a>
|
|
(defined below),
|
|
.\"
|
|
"succeeds" means matching the rest of the main pattern as well as the
|
|
alternative in the subpattern.
|
|
.
|
|
.
|
|
.SH "INTERNAL OPTION SETTING"
|
|
.rs
|
|
.sp
|
|
The settings of the PCRE_CASELESS, PCRE_MULTILINE, PCRE_DOTALL, and
|
|
PCRE_EXTENDED options can be changed from within the pattern by a sequence of
|
|
Perl option letters enclosed between "(?" and ")". The option letters are
|
|
.sp
|
|
i for PCRE_CASELESS
|
|
m for PCRE_MULTILINE
|
|
s for PCRE_DOTALL
|
|
x for PCRE_EXTENDED
|
|
.sp
|
|
For example, (?im) sets caseless, multiline matching. It is also possible to
|
|
unset these options by preceding the letter with a hyphen, and a combined
|
|
setting and unsetting such as (?im-sx), which sets PCRE_CASELESS and
|
|
PCRE_MULTILINE while unsetting PCRE_DOTALL and PCRE_EXTENDED, is also
|
|
permitted. If a letter appears both before and after the hyphen, the option is
|
|
unset.
|
|
.P
|
|
When an option change occurs at top level (that is, not inside subpattern
|
|
parentheses), the change applies to the remainder of the pattern that follows.
|
|
If the change is placed right at the start of a pattern, PCRE extracts it into
|
|
the global options (and it will therefore show up in data extracted by the
|
|
\fBpcre_fullinfo()\fP function).
|
|
.P
|
|
An option change within a subpattern affects only that part of the current
|
|
pattern that follows it, so
|
|
.sp
|
|
(a(?i)b)c
|
|
.sp
|
|
matches abc and aBc and no other strings (assuming PCRE_CASELESS is not used).
|
|
By this means, options can be made to have different settings in different
|
|
parts of the pattern. Any changes made in one alternative do carry on
|
|
into subsequent branches within the same subpattern. For example,
|
|
.sp
|
|
(a(?i)b|c)
|
|
.sp
|
|
matches "ab", "aB", "c", and "C", even though when matching "C" the first
|
|
branch is abandoned before the option setting. This is because the effects of
|
|
option settings happen at compile time. There would be some very weird
|
|
behaviour otherwise.
|
|
.P
|
|
The PCRE-specific options PCRE_DUPNAMES, PCRE_UNGREEDY, and PCRE_EXTRA can be
|
|
changed in the same way as the Perl-compatible options by using the characters
|
|
J, U and X respectively.
|
|
.
|
|
.
|
|
.\" HTML <a name="subpattern"></a>
|
|
.SH SUBPATTERNS
|
|
.rs
|
|
.sp
|
|
Subpatterns are delimited by parentheses (round brackets), which can be nested.
|
|
Turning part of a pattern into a subpattern does two things:
|
|
.sp
|
|
1. It localizes a set of alternatives. For example, the pattern
|
|
.sp
|
|
cat(aract|erpillar|)
|
|
.sp
|
|
matches one of the words "cat", "cataract", or "caterpillar". Without the
|
|
parentheses, it would match "cataract", "erpillar" or the empty string.
|
|
.sp
|
|
2. It sets up the subpattern as a capturing subpattern. This means that, when
|
|
the whole pattern matches, that portion of the subject string that matched the
|
|
subpattern is passed back to the caller via the \fIovector\fP argument of
|
|
\fBpcre_exec()\fP. Opening parentheses are counted from left to right (starting
|
|
from 1) to obtain numbers for the capturing subpatterns.
|
|
.P
|
|
For example, if the string "the red king" is matched against the pattern
|
|
.sp
|
|
the ((red|white) (king|queen))
|
|
.sp
|
|
the captured substrings are "red king", "red", and "king", and are numbered 1,
|
|
2, and 3, respectively.
|
|
.P
|
|
The fact that plain parentheses fulfil two functions is not always helpful.
|
|
There are often times when a grouping subpattern is required without a
|
|
capturing requirement. If an opening parenthesis is followed by a question mark
|
|
and a colon, the subpattern does not do any capturing, and is not counted when
|
|
computing the number of any subsequent capturing subpatterns. For example, if
|
|
the string "the white queen" is matched against the pattern
|
|
.sp
|
|
the ((?:red|white) (king|queen))
|
|
.sp
|
|
the captured substrings are "white queen" and "queen", and are numbered 1 and
|
|
2. The maximum number of capturing subpatterns is 65535, and the maximum depth
|
|
of nesting of all subpatterns, both capturing and non-capturing, is 200.
|
|
.P
|
|
As a convenient shorthand, if any option settings are required at the start of
|
|
a non-capturing subpattern, the option letters may appear between the "?" and
|
|
the ":". Thus the two patterns
|
|
.sp
|
|
(?i:saturday|sunday)
|
|
(?:(?i)saturday|sunday)
|
|
.sp
|
|
match exactly the same set of strings. Because alternative branches are tried
|
|
from left to right, and options are not reset until the end of the subpattern
|
|
is reached, an option setting in one branch does affect subsequent branches, so
|
|
the above patterns match "SUNDAY" as well as "Saturday".
|
|
.
|
|
.
|
|
.SH "NAMED SUBPATTERNS"
|
|
.rs
|
|
.sp
|
|
Identifying capturing parentheses by number is simple, but it can be very hard
|
|
to keep track of the numbers in complicated regular expressions. Furthermore,
|
|
if an expression is modified, the numbers may change. To help with this
|
|
difficulty, PCRE supports the naming of subpatterns, something that Perl does
|
|
not provide. The Python syntax (?P<name>...) is used. References to capturing
|
|
parentheses from other parts of the pattern, such as
|
|
.\" HTML <a href="#backreferences">
|
|
.\" </a>
|
|
backreferences,
|
|
.\"
|
|
.\" HTML <a href="#recursion">
|
|
.\" </a>
|
|
recursion,
|
|
.\"
|
|
and
|
|
.\" HTML <a href="#conditions">
|
|
.\" </a>
|
|
conditions,
|
|
.\"
|
|
can be made by name as well as by number.
|
|
.P
|
|
Names consist of up to 32 alphanumeric characters and underscores. Named
|
|
capturing parentheses are still allocated numbers as well as names. The PCRE
|
|
API provides function calls for extracting the name-to-number translation table
|
|
from a compiled pattern. There is also a convenience function for extracting a
|
|
captured substring by name.
|
|
.P
|
|
By default, a name must be unique within a pattern, but it is possible to relax
|
|
this constraint by setting the PCRE_DUPNAMES option at compile time. This can
|
|
be useful for patterns where only one instance of the named parentheses can
|
|
match. Suppose you want to match the name of a weekday, either as a 3-letter
|
|
abbreviation or as the full name, and in both cases you want to extract the
|
|
abbreviation. This pattern (ignoring the line breaks) does the job:
|
|
.sp
|
|
(?P<DN>Mon|Fri|Sun)(?:day)?|
|
|
(?P<DN>Tue)(?:sday)?|
|
|
(?P<DN>Wed)(?:nesday)?|
|
|
(?P<DN>Thu)(?:rsday)?|
|
|
(?P<DN>Sat)(?:urday)?
|
|
.sp
|
|
There are five capturing substrings, but only one is ever set after a match.
|
|
The convenience function for extracting the data by name returns the substring
|
|
for the first, and in this example, the only, subpattern of that name that
|
|
matched. This saves searching to find which numbered subpattern it was. If you
|
|
make a reference to a non-unique named subpattern from elsewhere in the
|
|
pattern, the one that corresponds to the lowest number is used. For further
|
|
details of the interfaces for handling named subpatterns, see the
|
|
.\" HREF
|
|
\fBpcreapi\fP
|
|
.\"
|
|
documentation.
|
|
.
|
|
.
|
|
.SH REPETITION
|
|
.rs
|
|
.sp
|
|
Repetition is specified by quantifiers, which can follow any of the following
|
|
items:
|
|
.sp
|
|
a literal data character
|
|
the . metacharacter
|
|
the \eC escape sequence
|
|
the \eX escape sequence (in UTF-8 mode with Unicode properties)
|
|
an escape such as \ed that matches a single character
|
|
a character class
|
|
a back reference (see next section)
|
|
a parenthesized subpattern (unless it is an assertion)
|
|
.sp
|
|
The general repetition quantifier specifies a minimum and maximum number of
|
|
permitted matches, by giving the two numbers in curly brackets (braces),
|
|
separated by a comma. The numbers must be less than 65536, and the first must
|
|
be less than or equal to the second. For example:
|
|
.sp
|
|
z{2,4}
|
|
.sp
|
|
matches "zz", "zzz", or "zzzz". A closing brace on its own is not a special
|
|
character. If the second number is omitted, but the comma is present, there is
|
|
no upper limit; if the second number and the comma are both omitted, the
|
|
quantifier specifies an exact number of required matches. Thus
|
|
.sp
|
|
[aeiou]{3,}
|
|
.sp
|
|
matches at least 3 successive vowels, but may match many more, while
|
|
.sp
|
|
\ed{8}
|
|
.sp
|
|
matches exactly 8 digits. An opening curly bracket that appears in a position
|
|
where a quantifier is not allowed, or one that does not match the syntax of a
|
|
quantifier, is taken as a literal character. For example, {,6} is not a
|
|
quantifier, but a literal string of four characters.
|
|
.P
|
|
In UTF-8 mode, quantifiers apply to UTF-8 characters rather than to individual
|
|
bytes. Thus, for example, \ex{100}{2} matches two UTF-8 characters, each of
|
|
which is represented by a two-byte sequence. Similarly, when Unicode property
|
|
support is available, \eX{3} matches three Unicode extended sequences, each of
|
|
which may be several bytes long (and they may be of different lengths).
|
|
.P
|
|
The quantifier {0} is permitted, causing the expression to behave as if the
|
|
previous item and the quantifier were not present.
|
|
.P
|
|
For convenience (and historical compatibility) the three most common
|
|
quantifiers have single-character abbreviations:
|
|
.sp
|
|
* is equivalent to {0,}
|
|
+ is equivalent to {1,}
|
|
? is equivalent to {0,1}
|
|
.sp
|
|
It is possible to construct infinite loops by following a subpattern that can
|
|
match no characters with a quantifier that has no upper limit, for example:
|
|
.sp
|
|
(a?)*
|
|
.sp
|
|
Earlier versions of Perl and PCRE used to give an error at compile time for
|
|
such patterns. However, because there are cases where this can be useful, such
|
|
patterns are now accepted, but if any repetition of the subpattern does in fact
|
|
match no characters, the loop is forcibly broken.
|
|
.P
|
|
By default, the quantifiers are "greedy", that is, they match as much as
|
|
possible (up to the maximum number of permitted times), without causing the
|
|
rest of the pattern to fail. The classic example of where this gives problems
|
|
is in trying to match comments in C programs. These appear between /* and */
|
|
and within the comment, individual * and / characters may appear. An attempt to
|
|
match C comments by applying the pattern
|
|
.sp
|
|
/\e*.*\e*/
|
|
.sp
|
|
to the string
|
|
.sp
|
|
/* first comment */ not comment /* second comment */
|
|
.sp
|
|
fails, because it matches the entire string owing to the greediness of the .*
|
|
item.
|
|
.P
|
|
However, if a quantifier is followed by a question mark, it ceases to be
|
|
greedy, and instead matches the minimum number of times possible, so the
|
|
pattern
|
|
.sp
|
|
/\e*.*?\e*/
|
|
.sp
|
|
does the right thing with the C comments. The meaning of the various
|
|
quantifiers is not otherwise changed, just the preferred number of matches.
|
|
Do not confuse this use of question mark with its use as a quantifier in its
|
|
own right. Because it has two uses, it can sometimes appear doubled, as in
|
|
.sp
|
|
\ed??\ed
|
|
.sp
|
|
which matches one digit by preference, but can match two if that is the only
|
|
way the rest of the pattern matches.
|
|
.P
|
|
If the PCRE_UNGREEDY option is set (an option which is not available in Perl),
|
|
the quantifiers are not greedy by default, but individual ones can be made
|
|
greedy by following them with a question mark. In other words, it inverts the
|
|
default behaviour.
|
|
.P
|
|
When a parenthesized subpattern is quantified with a minimum repeat count that
|
|
is greater than 1 or with a limited maximum, more memory is required for the
|
|
compiled pattern, in proportion to the size of the minimum or maximum.
|
|
.P
|
|
If a pattern starts with .* or .{0,} and the PCRE_DOTALL option (equivalent
|
|
to Perl's /s) is set, thus allowing the . to match newlines, the pattern is
|
|
implicitly anchored, because whatever follows will be tried against every
|
|
character position in the subject string, so there is no point in retrying the
|
|
overall match at any position after the first. PCRE normally treats such a
|
|
pattern as though it were preceded by \eA.
|
|
.P
|
|
In cases where it is known that the subject string contains no newlines, it is
|
|
worth setting PCRE_DOTALL in order to obtain this optimization, or
|
|
alternatively using ^ to indicate anchoring explicitly.
|
|
.P
|
|
However, there is one situation where the optimization cannot be used. When .*
|
|
is inside capturing parentheses that are the subject of a backreference
|
|
elsewhere in the pattern, a match at the start may fail, and a later one
|
|
succeed. Consider, for example:
|
|
.sp
|
|
(.*)abc\e1
|
|
.sp
|
|
If the subject is "xyz123abc123" the match point is the fourth character. For
|
|
this reason, such a pattern is not implicitly anchored.
|
|
.P
|
|
When a capturing subpattern is repeated, the value captured is the substring
|
|
that matched the final iteration. For example, after
|
|
.sp
|
|
(tweedle[dume]{3}\es*)+
|
|
.sp
|
|
has matched "tweedledum tweedledee" the value of the captured substring is
|
|
"tweedledee". However, if there are nested capturing subpatterns, the
|
|
corresponding captured values may have been set in previous iterations. For
|
|
example, after
|
|
.sp
|
|
/(a|(b))+/
|
|
.sp
|
|
matches "aba" the value of the second captured substring is "b".
|
|
.
|
|
.
|
|
.\" HTML <a name="atomicgroup"></a>
|
|
.SH "ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS"
|
|
.rs
|
|
.sp
|
|
With both maximizing and minimizing repetition, failure of what follows
|
|
normally causes the repeated item to be re-evaluated to see if a different
|
|
number of repeats allows the rest of the pattern to match. Sometimes it is
|
|
useful to prevent this, either to change the nature of the match, or to cause
|
|
it fail earlier than it otherwise might, when the author of the pattern knows
|
|
there is no point in carrying on.
|
|
.P
|
|
Consider, for example, the pattern \ed+foo when applied to the subject line
|
|
.sp
|
|
123456bar
|
|
.sp
|
|
After matching all 6 digits and then failing to match "foo", the normal
|
|
action of the matcher is to try again with only 5 digits matching the \ed+
|
|
item, and then with 4, and so on, before ultimately failing. "Atomic grouping"
|
|
(a term taken from Jeffrey Friedl's book) provides the means for specifying
|
|
that once a subpattern has matched, it is not to be re-evaluated in this way.
|
|
.P
|
|
If we use atomic grouping for the previous example, the matcher would give up
|
|
immediately on failing to match "foo" the first time. The notation is a kind of
|
|
special parenthesis, starting with (?> as in this example:
|
|
.sp
|
|
(?>\ed+)foo
|
|
.sp
|
|
This kind of parenthesis "locks up" the part of the pattern it contains once
|
|
it has matched, and a failure further into the pattern is prevented from
|
|
backtracking into it. Backtracking past it to previous items, however, works as
|
|
normal.
|
|
.P
|
|
An alternative description is that a subpattern of this type matches the string
|
|
of characters that an identical standalone pattern would match, if anchored at
|
|
the current point in the subject string.
|
|
.P
|
|
Atomic grouping subpatterns are not capturing subpatterns. Simple cases such as
|
|
the above example can be thought of as a maximizing repeat that must swallow
|
|
everything it can. So, while both \ed+ and \ed+? are prepared to adjust the
|
|
number of digits they match in order to make the rest of the pattern match,
|
|
(?>\ed+) can only match an entire sequence of digits.
|
|
.P
|
|
Atomic groups in general can of course contain arbitrarily complicated
|
|
subpatterns, and can be nested. However, when the subpattern for an atomic
|
|
group is just a single repeated item, as in the example above, a simpler
|
|
notation, called a "possessive quantifier" can be used. This consists of an
|
|
additional + character following a quantifier. Using this notation, the
|
|
previous example can be rewritten as
|
|
.sp
|
|
\ed++foo
|
|
.sp
|
|
Possessive quantifiers are always greedy; the setting of the PCRE_UNGREEDY
|
|
option is ignored. They are a convenient notation for the simpler forms of
|
|
atomic group. However, there is no difference in the meaning or processing of a
|
|
possessive quantifier and the equivalent atomic group.
|
|
.P
|
|
The possessive quantifier syntax is an extension to the Perl syntax. Jeffrey
|
|
Friedl originated the idea (and the name) in the first edition of his book.
|
|
Mike McCloskey liked it, so implemented it when he built Sun's Java package,
|
|
and PCRE copied it from there.
|
|
.P
|
|
When a pattern contains an unlimited repeat inside a subpattern that can itself
|
|
be repeated an unlimited number of times, the use of an atomic group is the
|
|
only way to avoid some failing matches taking a very long time indeed. The
|
|
pattern
|
|
.sp
|
|
(\eD+|<\ed+>)*[!?]
|
|
.sp
|
|
matches an unlimited number of substrings that either consist of non-digits, or
|
|
digits enclosed in <>, followed by either ! or ?. When it matches, it runs
|
|
quickly. However, if it is applied to
|
|
.sp
|
|
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
|
|
.sp
|
|
it takes a long time before reporting failure. This is because the string can
|
|
be divided between the internal \eD+ repeat and the external * repeat in a
|
|
large number of ways, and all have to be tried. (The example uses [!?] rather
|
|
than a single character at the end, because both PCRE and Perl have an
|
|
optimization that allows for fast failure when a single character is used. They
|
|
remember the last single character that is required for a match, and fail early
|
|
if it is not present in the string.) If the pattern is changed so that it uses
|
|
an atomic group, like this:
|
|
.sp
|
|
((?>\eD+)|<\ed+>)*[!?]
|
|
.sp
|
|
sequences of non-digits cannot be broken, and failure happens quickly.
|
|
.
|
|
.
|
|
.\" HTML <a name="backreferences"></a>
|
|
.SH "BACK REFERENCES"
|
|
.rs
|
|
.sp
|
|
Outside a character class, a backslash followed by a digit greater than 0 (and
|
|
possibly further digits) is a back reference to a capturing subpattern earlier
|
|
(that is, to its left) in the pattern, provided there have been that many
|
|
previous capturing left parentheses.
|
|
.P
|
|
However, if the decimal number following the backslash is less than 10, it is
|
|
always taken as a back reference, and causes an error only if there are not
|
|
that many capturing left parentheses in the entire pattern. In other words, the
|
|
parentheses that are referenced need not be to the left of the reference for
|
|
numbers less than 10. A "forward back reference" of this type can make sense
|
|
when a repetition is involved and the subpattern to the right has participated
|
|
in an earlier iteration.
|
|
.P
|
|
It is not possible to have a numerical "forward back reference" to subpattern
|
|
whose number is 10 or more. However, a back reference to any subpattern is
|
|
possible using named parentheses (see below). See also the subsection entitled
|
|
"Non-printing characters"
|
|
.\" HTML <a href="#digitsafterbackslash">
|
|
.\" </a>
|
|
above
|
|
.\"
|
|
for further details of the handling of digits following a backslash.
|
|
.P
|
|
A back reference matches whatever actually matched the capturing subpattern in
|
|
the current subject string, rather than anything matching the subpattern
|
|
itself (see
|
|
.\" HTML <a href="#subpatternsassubroutines">
|
|
.\" </a>
|
|
"Subpatterns as subroutines"
|
|
.\"
|
|
below for a way of doing that). So the pattern
|
|
.sp
|
|
(sens|respons)e and \e1ibility
|
|
.sp
|
|
matches "sense and sensibility" and "response and responsibility", but not
|
|
"sense and responsibility". If caseful matching is in force at the time of the
|
|
back reference, the case of letters is relevant. For example,
|
|
.sp
|
|
((?i)rah)\es+\e1
|
|
.sp
|
|
matches "rah rah" and "RAH RAH", but not "RAH rah", even though the original
|
|
capturing subpattern is matched caselessly.
|
|
.P
|
|
Back references to named subpatterns use the Python syntax (?P=name). We could
|
|
rewrite the above example as follows:
|
|
.sp
|
|
(?P<p1>(?i)rah)\es+(?P=p1)
|
|
.sp
|
|
A subpattern that is referenced by name may appear in the pattern before or
|
|
after the reference.
|
|
.P
|
|
There may be more than one back reference to the same subpattern. If a
|
|
subpattern has not actually been used in a particular match, any back
|
|
references to it always fail. For example, the pattern
|
|
.sp
|
|
(a|(bc))\e2
|
|
.sp
|
|
always fails if it starts to match "a" rather than "bc". Because there may be
|
|
many capturing parentheses in a pattern, all digits following the backslash are
|
|
taken as part of a potential back reference number. If the pattern continues
|
|
with a digit character, some delimiter must be used to terminate the back
|
|
reference. If the PCRE_EXTENDED option is set, this can be whitespace.
|
|
Otherwise an empty comment (see
|
|
.\" HTML <a href="#comments">
|
|
.\" </a>
|
|
"Comments"
|
|
.\"
|
|
below) can be used.
|
|
.P
|
|
A back reference that occurs inside the parentheses to which it refers fails
|
|
when the subpattern is first used, so, for example, (a\e1) never matches.
|
|
However, such references can be useful inside repeated subpatterns. For
|
|
example, the pattern
|
|
.sp
|
|
(a|b\e1)+
|
|
.sp
|
|
matches any number of "a"s and also "aba", "ababbaa" etc. At each iteration of
|
|
the subpattern, the back reference matches the character string corresponding
|
|
to the previous iteration. In order for this to work, the pattern must be such
|
|
that the first iteration does not need to match the back reference. This can be
|
|
done using alternation, as in the example above, or by a quantifier with a
|
|
minimum of zero.
|
|
.
|
|
.
|
|
.\" HTML <a name="bigassertions"></a>
|
|
.SH ASSERTIONS
|
|
.rs
|
|
.sp
|
|
An assertion is a test on the characters following or preceding the current
|
|
matching point that does not actually consume any characters. The simple
|
|
assertions coded as \eb, \eB, \eA, \eG, \eZ, \ez, ^ and $ are described
|
|
.\" HTML <a href="#smallassertions">
|
|
.\" </a>
|
|
above.
|
|
.\"
|
|
.P
|
|
More complicated assertions are coded as subpatterns. There are two kinds:
|
|
those that look ahead of the current position in the subject string, and those
|
|
that look behind it. An assertion subpattern is matched in the normal way,
|
|
except that it does not cause the current matching position to be changed.
|
|
.P
|
|
Assertion subpatterns are not capturing subpatterns, and may not be repeated,
|
|
because it makes no sense to assert the same thing several times. If any kind
|
|
of assertion contains capturing subpatterns within it, these are counted for
|
|
the purposes of numbering the capturing subpatterns in the whole pattern.
|
|
However, substring capturing is carried out only for positive assertions,
|
|
because it does not make sense for negative assertions.
|
|
.
|
|
.
|
|
.SS "Lookahead assertions"
|
|
.rs
|
|
.sp
|
|
Lookahead assertions start with (?= for positive assertions and (?! for
|
|
negative assertions. For example,
|
|
.sp
|
|
\ew+(?=;)
|
|
.sp
|
|
matches a word followed by a semicolon, but does not include the semicolon in
|
|
the match, and
|
|
.sp
|
|
foo(?!bar)
|
|
.sp
|
|
matches any occurrence of "foo" that is not followed by "bar". Note that the
|
|
apparently similar pattern
|
|
.sp
|
|
(?!foo)bar
|
|
.sp
|
|
does not find an occurrence of "bar" that is preceded by something other than
|
|
"foo"; it finds any occurrence of "bar" whatsoever, because the assertion
|
|
(?!foo) is always true when the next three characters are "bar". A
|
|
lookbehind assertion is needed to achieve the other effect.
|
|
.P
|
|
If you want to force a matching failure at some point in a pattern, the most
|
|
convenient way to do it is with (?!) because an empty string always matches, so
|
|
an assertion that requires there not to be an empty string must always fail.
|
|
.
|
|
.
|
|
.\" HTML <a name="lookbehind"></a>
|
|
.SS "Lookbehind assertions"
|
|
.rs
|
|
.sp
|
|
Lookbehind assertions start with (?<= for positive assertions and (?<! for
|
|
negative assertions. For example,
|
|
.sp
|
|
(?<!foo)bar
|
|
.sp
|
|
does find an occurrence of "bar" that is not preceded by "foo". The contents of
|
|
a lookbehind assertion are restricted such that all the strings it matches must
|
|
have a fixed length. However, if there are several top-level alternatives, they
|
|
do not all have to have the same fixed length. Thus
|
|
.sp
|
|
(?<=bullock|donkey)
|
|
.sp
|
|
is permitted, but
|
|
.sp
|
|
(?<!dogs?|cats?)
|
|
.sp
|
|
causes an error at compile time. Branches that match different length strings
|
|
are permitted only at the top level of a lookbehind assertion. This is an
|
|
extension compared with Perl (at least for 5.8), which requires all branches to
|
|
match the same length of string. An assertion such as
|
|
.sp
|
|
(?<=ab(c|de))
|
|
.sp
|
|
is not permitted, because its single top-level branch can match two different
|
|
lengths, but it is acceptable if rewritten to use two top-level branches:
|
|
.sp
|
|
(?<=abc|abde)
|
|
.sp
|
|
The implementation of lookbehind assertions is, for each alternative, to
|
|
temporarily move the current position back by the fixed width and then try to
|
|
match. If there are insufficient characters before the current position, the
|
|
match is deemed to fail.
|
|
.P
|
|
PCRE does not allow the \eC escape (which matches a single byte in UTF-8 mode)
|
|
to appear in lookbehind assertions, because it makes it impossible to calculate
|
|
the length of the lookbehind. The \eX escape, which can match different numbers
|
|
of bytes, is also not permitted.
|
|
.P
|
|
Atomic groups can be used in conjunction with lookbehind assertions to specify
|
|
efficient matching at the end of the subject string. Consider a simple pattern
|
|
such as
|
|
.sp
|
|
abcd$
|
|
.sp
|
|
when applied to a long string that does not match. Because matching proceeds
|
|
from left to right, PCRE will look for each "a" in the subject and then see if
|
|
what follows matches the rest of the pattern. If the pattern is specified as
|
|
.sp
|
|
^.*abcd$
|
|
.sp
|
|
the initial .* matches the entire string at first, but when this fails (because
|
|
there is no following "a"), it backtracks to match all but the last character,
|
|
then all but the last two characters, and so on. Once again the search for "a"
|
|
covers the entire string, from right to left, so we are no better off. However,
|
|
if the pattern is written as
|
|
.sp
|
|
^(?>.*)(?<=abcd)
|
|
.sp
|
|
or, equivalently, using the possessive quantifier syntax,
|
|
.sp
|
|
^.*+(?<=abcd)
|
|
.sp
|
|
there can be no backtracking for the .* item; it can match only the entire
|
|
string. The subsequent lookbehind assertion does a single test on the last four
|
|
characters. If it fails, the match fails immediately. For long strings, this
|
|
approach makes a significant difference to the processing time.
|
|
.
|
|
.
|
|
.SS "Using multiple assertions"
|
|
.rs
|
|
.sp
|
|
Several assertions (of any sort) may occur in succession. For example,
|
|
.sp
|
|
(?<=\ed{3})(?<!999)foo
|
|
.sp
|
|
matches "foo" preceded by three digits that are not "999". Notice that each of
|
|
the assertions is applied independently at the same point in the subject
|
|
string. First there is a check that the previous three characters are all
|
|
digits, and then there is a check that the same three characters are not "999".
|
|
This pattern does \fInot\fP match "foo" preceded by six characters, the first
|
|
of which are digits and the last three of which are not "999". For example, it
|
|
doesn't match "123abcfoo". A pattern to do that is
|
|
.sp
|
|
(?<=\ed{3}...)(?<!999)foo
|
|
.sp
|
|
This time the first assertion looks at the preceding six characters, checking
|
|
that the first three are digits, and then the second assertion checks that the
|
|
preceding three characters are not "999".
|
|
.P
|
|
Assertions can be nested in any combination. For example,
|
|
.sp
|
|
(?<=(?<!foo)bar)baz
|
|
.sp
|
|
matches an occurrence of "baz" that is preceded by "bar" which in turn is not
|
|
preceded by "foo", while
|
|
.sp
|
|
(?<=\ed{3}(?!999)...)foo
|
|
.sp
|
|
is another pattern that matches "foo" preceded by three digits and any three
|
|
characters that are not "999".
|
|
.
|
|
.
|
|
.\" HTML <a name="conditions"></a>
|
|
.SH "CONDITIONAL SUBPATTERNS"
|
|
.rs
|
|
.sp
|
|
It is possible to cause the matching process to obey a subpattern
|
|
conditionally or to choose between two alternative subpatterns, depending on
|
|
the result of an assertion, or whether a previous capturing subpattern matched
|
|
or not. The two possible forms of conditional subpattern are
|
|
.sp
|
|
(?(condition)yes-pattern)
|
|
(?(condition)yes-pattern|no-pattern)
|
|
.sp
|
|
If the condition is satisfied, the yes-pattern is used; otherwise the
|
|
no-pattern (if present) is used. If there are more than two alternatives in the
|
|
subpattern, a compile-time error occurs.
|
|
.P
|
|
There are three kinds of condition. If the text between the parentheses
|
|
consists of a sequence of digits, or a sequence of alphanumeric characters and
|
|
underscores, the condition is satisfied if the capturing subpattern of that
|
|
number or name has previously matched. There is a possible ambiguity here,
|
|
because subpattern names may consist entirely of digits. PCRE looks first for a
|
|
named subpattern; if it cannot find one and the text consists entirely of
|
|
digits, it looks for a subpattern of that number, which must be greater than
|
|
zero. Using subpattern names that consist entirely of digits is not
|
|
recommended.
|
|
.P
|
|
Consider the following pattern, which contains non-significant white space to
|
|
make it more readable (assume the PCRE_EXTENDED option) and to divide it into
|
|
three parts for ease of discussion:
|
|
.sp
|
|
( \e( )? [^()]+ (?(1) \e) )
|
|
.sp
|
|
The first part matches an optional opening parenthesis, and if that
|
|
character is present, sets it as the first captured substring. The second part
|
|
matches one or more characters that are not parentheses. The third part is a
|
|
conditional subpattern that tests whether the first set of parentheses matched
|
|
or not. If they did, that is, if subject started with an opening parenthesis,
|
|
the condition is true, and so the yes-pattern is executed and a closing
|
|
parenthesis is required. Otherwise, since no-pattern is not present, the
|
|
subpattern matches nothing. In other words, this pattern matches a sequence of
|
|
non-parentheses, optionally enclosed in parentheses. Rewriting it to use a
|
|
named subpattern gives this:
|
|
.sp
|
|
(?P<OPEN> \e( )? [^()]+ (?(OPEN) \e) )
|
|
.sp
|
|
If the condition is the string (R), and there is no subpattern with the name R,
|
|
the condition is satisfied if a recursive call to the pattern or subpattern has
|
|
been made. At "top level", the condition is false. This is a PCRE extension.
|
|
Recursive patterns are described in the next section.
|
|
.P
|
|
If the condition is not a sequence of digits or (R), it must be an assertion.
|
|
This may be a positive or negative lookahead or lookbehind assertion. Consider
|
|
this pattern, again containing non-significant white space, and with the two
|
|
alternatives on the second line:
|
|
.sp
|
|
(?(?=[^a-z]*[a-z])
|
|
\ed{2}-[a-z]{3}-\ed{2} | \ed{2}-\ed{2}-\ed{2} )
|
|
.sp
|
|
The condition is a positive lookahead assertion that matches an optional
|
|
sequence of non-letters followed by a letter. In other words, it tests for the
|
|
presence of at least one letter in the subject. If a letter is found, the
|
|
subject is matched against the first alternative; otherwise it is matched
|
|
against the second. This pattern matches strings in one of the two forms
|
|
dd-aaa-dd or dd-dd-dd, where aaa are letters and dd are digits.
|
|
.
|
|
.
|
|
.\" HTML <a name="comments"></a>
|
|
.SH COMMENTS
|
|
.rs
|
|
.sp
|
|
The sequence (?# marks the start of a comment that continues up to the next
|
|
closing parenthesis. Nested parentheses are not permitted. The characters
|
|
that make up a comment play no part in the pattern matching at all.
|
|
.P
|
|
If the PCRE_EXTENDED option is set, an unescaped # character outside a
|
|
character class introduces a comment that continues to immediately after the
|
|
next newline in the pattern.
|
|
.
|
|
.
|
|
.\" HTML <a name="recursion"></a>
|
|
.SH "RECURSIVE PATTERNS"
|
|
.rs
|
|
.sp
|
|
Consider the problem of matching a string in parentheses, allowing for
|
|
unlimited nested parentheses. Without the use of recursion, the best that can
|
|
be done is to use a pattern that matches up to some fixed depth of nesting. It
|
|
is not possible to handle an arbitrary nesting depth. Perl provides a facility
|
|
that allows regular expressions to recurse (amongst other things). It does this
|
|
by interpolating Perl code in the expression at run time, and the code can
|
|
refer to the expression itself. A Perl pattern to solve the parentheses problem
|
|
can be created like this:
|
|
.sp
|
|
$re = qr{\e( (?: (?>[^()]+) | (?p{$re}) )* \e)}x;
|
|
.sp
|
|
The (?p{...}) item interpolates Perl code at run time, and in this case refers
|
|
recursively to the pattern in which it appears. Obviously, PCRE cannot support
|
|
the interpolation of Perl code. Instead, it supports some special syntax for
|
|
recursion of the entire pattern, and also for individual subpattern recursion.
|
|
.P
|
|
The special item that consists of (? followed by a number greater than zero and
|
|
a closing parenthesis is a recursive call of the subpattern of the given
|
|
number, provided that it occurs inside that subpattern. (If not, it is a
|
|
"subroutine" call, which is described in the next section.) The special item
|
|
(?R) is a recursive call of the entire regular expression.
|
|
.P
|
|
A recursive subpattern call is always treated as an atomic group. That is, once
|
|
it has matched some of the subject string, it is never re-entered, even if
|
|
it contains untried alternatives and there is a subsequent matching failure.
|
|
.P
|
|
This PCRE pattern solves the nested parentheses problem (assume the
|
|
PCRE_EXTENDED option is set so that white space is ignored):
|
|
.sp
|
|
\e( ( (?>[^()]+) | (?R) )* \e)
|
|
.sp
|
|
First it matches an opening parenthesis. Then it matches any number of
|
|
substrings which can either be a sequence of non-parentheses, or a recursive
|
|
match of the pattern itself (that is, a correctly parenthesized substring).
|
|
Finally there is a closing parenthesis.
|
|
.P
|
|
If this were part of a larger pattern, you would not want to recurse the entire
|
|
pattern, so instead you could use this:
|
|
.sp
|
|
( \e( ( (?>[^()]+) | (?1) )* \e) )
|
|
.sp
|
|
We have put the pattern into parentheses, and caused the recursion to refer to
|
|
them instead of the whole pattern. In a larger pattern, keeping track of
|
|
parenthesis numbers can be tricky. It may be more convenient to use named
|
|
parentheses instead. For this, PCRE uses (?P>name), which is an extension to
|
|
the Python syntax that PCRE uses for named parentheses (Perl does not provide
|
|
named parentheses). We could rewrite the above example as follows:
|
|
.sp
|
|
(?P<pn> \e( ( (?>[^()]+) | (?P>pn) )* \e) )
|
|
.sp
|
|
This particular example pattern contains nested unlimited repeats, and so the
|
|
use of atomic grouping for matching strings of non-parentheses is important
|
|
when applying the pattern to strings that do not match. For example, when this
|
|
pattern is applied to
|
|
.sp
|
|
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()
|
|
.sp
|
|
it yields "no match" quickly. However, if atomic grouping is not used,
|
|
the match runs for a very long time indeed because there are so many different
|
|
ways the + and * repeats can carve up the subject, and all have to be tested
|
|
before failure can be reported.
|
|
.P
|
|
At the end of a match, the values set for any capturing subpatterns are those
|
|
from the outermost level of the recursion at which the subpattern value is set.
|
|
If you want to obtain intermediate values, a callout function can be used (see
|
|
the next section and the
|
|
.\" HREF
|
|
\fBpcrecallout\fP
|
|
.\"
|
|
documentation). If the pattern above is matched against
|
|
.sp
|
|
(ab(cd)ef)
|
|
.sp
|
|
the value for the capturing parentheses is "ef", which is the last value taken
|
|
on at the top level. If additional parentheses are added, giving
|
|
.sp
|
|
\e( ( ( (?>[^()]+) | (?R) )* ) \e)
|
|
^ ^
|
|
^ ^
|
|
.sp
|
|
the string they capture is "ab(cd)ef", the contents of the top level
|
|
parentheses. If there are more than 15 capturing parentheses in a pattern, PCRE
|
|
has to obtain extra memory to store data during a recursion, which it does by
|
|
using \fBpcre_malloc\fP, freeing it via \fBpcre_free\fP afterwards. If no
|
|
memory can be obtained, the match fails with the PCRE_ERROR_NOMEMORY error.
|
|
.P
|
|
Do not confuse the (?R) item with the condition (R), which tests for recursion.
|
|
Consider this pattern, which matches text in angle brackets, allowing for
|
|
arbitrary nesting. Only digits are allowed in nested brackets (that is, when
|
|
recursing), whereas any characters are permitted at the outer level.
|
|
.sp
|
|
< (?: (?(R) \ed++ | [^<>]*+) | (?R)) * >
|
|
.sp
|
|
In this pattern, (?(R) is the start of a conditional subpattern, with two
|
|
different alternatives for the recursive and non-recursive cases. The (?R) item
|
|
is the actual recursive call.
|
|
.
|
|
.
|
|
.\" HTML <a name="subpatternsassubroutines"></a>
|
|
.SH "SUBPATTERNS AS SUBROUTINES"
|
|
.rs
|
|
.sp
|
|
If the syntax for a recursive subpattern reference (either by number or by
|
|
name) is used outside the parentheses to which it refers, it operates like a
|
|
subroutine in a programming language. An earlier example pointed out that the
|
|
pattern
|
|
.sp
|
|
(sens|respons)e and \e1ibility
|
|
.sp
|
|
matches "sense and sensibility" and "response and responsibility", but not
|
|
"sense and responsibility". If instead the pattern
|
|
.sp
|
|
(sens|respons)e and (?1)ibility
|
|
.sp
|
|
is used, it does match "sense and responsibility" as well as the other two
|
|
strings. Such references, if given numerically, must follow the subpattern to
|
|
which they refer. However, named references can refer to later subpatterns.
|
|
.P
|
|
Like recursive subpatterns, a "subroutine" call is always treated as an atomic
|
|
group. That is, once it has matched some of the subject string, it is never
|
|
re-entered, even if it contains untried alternatives and there is a subsequent
|
|
matching failure.
|
|
.
|
|
.
|
|
.SH CALLOUTS
|
|
.rs
|
|
.sp
|
|
Perl has a feature whereby using the sequence (?{...}) causes arbitrary Perl
|
|
code to be obeyed in the middle of matching a regular expression. This makes it
|
|
possible, amongst other things, to extract different substrings that match the
|
|
same pair of parentheses when there is a repetition.
|
|
.P
|
|
PCRE provides a similar feature, but of course it cannot obey arbitrary Perl
|
|
code. The feature is called "callout". The caller of PCRE provides an external
|
|
function by putting its entry point in the global variable \fIpcre_callout\fP.
|
|
By default, this variable contains NULL, which disables all calling out.
|
|
.P
|
|
Within a regular expression, (?C) indicates the points at which the external
|
|
function is to be called. If you want to identify different callout points, you
|
|
can put a number less than 256 after the letter C. The default value is zero.
|
|
For example, this pattern has two callout points:
|
|
.sp
|
|
(?C1)\dabc(?C2)def
|
|
.sp
|
|
If the PCRE_AUTO_CALLOUT flag is passed to \fBpcre_compile()\fP, callouts are
|
|
automatically installed before each item in the pattern. They are all numbered
|
|
255.
|
|
.P
|
|
During matching, when PCRE reaches a callout point (and \fIpcre_callout\fP is
|
|
set), the external function is called. It is provided with the number of the
|
|
callout, the position in the pattern, and, optionally, one item of data
|
|
originally supplied by the caller of \fBpcre_exec()\fP. The callout function
|
|
may cause matching to proceed, to backtrack, or to fail altogether. A complete
|
|
description of the interface to the callout function is given in the
|
|
.\" HREF
|
|
\fBpcrecallout\fP
|
|
.\"
|
|
documentation.
|
|
.P
|
|
.in 0
|
|
Last updated: 06 June 2006
|
|
.br
|
|
Copyright (c) 1997-2006 University of Cambridge.
|