embedaddon/pcre/doc/html/pcrecompat.html - view

File: [ELWIX - Embedded LightWeight unIX -] / embedaddon / pcre / doc / html / pcrecompat.html
Revision 1.1.1.5 (vendor branch): download - view: text, annotated - select for diffs - revision graph
Sun Jun 15 19:46:05 2014 UTC (10 years, 1 month ago) by misho
Branches: pcre, MAIN
CVS tags: v8_34, HEAD

pcre 8.34

1: <html> 2: <head> 3: <title>pcrecompat specification</title> 4: </head> 5: <body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB"> 6: <h1>pcrecompat man page</h1> 7:  8: Return to the <a href="index.html">PCRE index page</a>. 9:  10:  11: This page is part of the PCRE HTML documentation. It was generated automatically 12: from the original man page. If there is any nonsense in it, please consult the 13: man page, in case the conversion went wrong. 14:   15:   16: DIFFERENCES BETWEEN PCRE AND PERL 17:   18:  19: This document describes the differences in the ways that PCRE and Perl handle 20: regular expressions. The differences described here are with respect to Perl 21: versions 5.10 and above. 22:  23:  24: 1. PCRE has only a subset of Perl's Unicode support. Details of what it does 25: have are given in the 26: <a href="pcreunicode.html">pcreunicode</a> 27: page. 28:  29:  30: 2. PCRE allows repeat quantifiers only on parenthesized assertions, but they do 31: not mean what you might think. For example, (?!a){3} does not assert that the 32: next three characters are not "a". It just asserts that the next character is 33: not "a" three times (in principle: PCRE optimizes this to run the assertion 34: just once). Perl allows repeat quantifiers on other assertions such as \b, but 35: these do not seem to have any use. 36:  37:  38: 3. Capturing subpatterns that occur inside negative lookahead assertions are 39: counted, but their entries in the offsets vector are never set. Perl sometimes 40: (but not always) sets its numerical variables from inside negative assertions. 41:  42:  43: 4. Though binary zero characters are supported in the subject string, they are 44: not allowed in a pattern string because it is passed as a normal C string, 45: terminated by zero. The escape sequence \0 can be used in the pattern to 46: represent a binary zero. 47:  48:  49: 5. The following Perl escape sequences are not supported: \l, \u, \L, 50: \U, and \N when followed by a character name or Unicode value. (\N on its 51: own, matching a non-newline character, is supported.) In fact these are 52: implemented by Perl's general string-handling and are not part of its pattern 53: matching engine. If any of these are encountered by PCRE, an error is 54: generated by default. However, if the PCRE_JAVASCRIPT_COMPAT option is set, 55: \U and \u are interpreted as JavaScript interprets them. 56:  57:  58: 6. The Perl escape sequences \p, \P, and \X are supported only if PCRE is 59: built with Unicode character property support. The properties that can be 60: tested with \p and \P are limited to the general category properties such as 61: Lu and Nd, script names such as Greek or Han, and the derived properties Any 62: and L&. PCRE does support the Cs (surrogate) property, which Perl does not; the 63: Perl documentation says "Because Perl hides the need for the user to understand 64: the internal representation of Unicode characters, there is no need to 65: implement the somewhat messy concept of surrogates." 66:  67:  68: 7. PCRE does support the \Q...\E escape for quoting substrings. Characters in 69: between are treated as literals. This is slightly different from Perl in that $ 70: and @ are also handled as literals inside the quotes. In Perl, they cause 71: variable interpolation (but of course PCRE does not have variables). Note the 72: following examples: 73: <pre> 74: Pattern PCRE matches Perl matches 75: 76: \Qabc$xyz\E abc$xyz abc followed by the contents of $xyz 77: \Qabc\$xyz\E abc\$xyz abc\$xyz 78: \Qabc\E\$\Qxyz\E abc$xyz abc$xyz 79: </pre> 80: The \Q...\E sequence is recognized both inside and outside character classes. 81:  82:  83: 8. Fairly obviously, PCRE does not support the (?{code}) and (??{code}) 84: constructions. However, there is support for recursive patterns. This is not 85: available in Perl 5.8, but it is in Perl 5.10. Also, the PCRE "callout" 86: feature allows an external function to be called during pattern matching. See 87: the 88: <a href="pcrecallout.html">pcrecallout</a> 89: documentation for details. 90:  91:  92: 9. Subpatterns that are called as subroutines (whether or not recursively) are 93: always treated as atomic groups in PCRE. This is like Python, but unlike Perl. 94: Captured values that are set outside a subroutine call can be reference from 95: inside in PCRE, but not in Perl. There is a discussion that explains these 96: differences in more detail in the 97: <a href="pcrepattern.html#recursiondifference">section on recursion differences from Perl</a> 98: in the 99: <a href="pcrepattern.html">pcrepattern</a> 100: page. 101:  102:  103: 10. If any of the backtracking control verbs are used in a subpattern that is 104: called as a subroutine (whether or not recursively), their effect is confined 105: to that subpattern; it does not extend to the surrounding pattern. This is not 106: always the case in Perl. In particular, if (*THEN) is present in a group that 107: is called as a subroutine, its action is limited to that group, even if the 108: group does not contain any | characters. Note that such subpatterns are 109: processed as anchored at the point where they are tested. 110:  111:  112: 11. If a pattern contains more than one backtracking control verb, the first 113: one that is backtracked onto acts. For example, in the pattern 114: A(*COMMIT)B(*PRUNE)C a failure in B triggers (*COMMIT), but a failure in C 115: triggers (*PRUNE). Perl's behaviour is more complex; in many cases it is the 116: same as PCRE, but there are examples where it differs. 117:  118:  119: 12. Most backtracking verbs in assertions have their normal actions. They are 120: not confined to the assertion. 121:  122:  123: 13. There are some differences that are concerned with the settings of captured 124: strings when part of a pattern is repeated. For example, matching "aba" against 125: the pattern /^(a(b)?)+$/ in Perl leaves $2 unset, but in PCRE it is set to "b". 126:  127:  128: 14. PCRE's handling of duplicate subpattern numbers and duplicate subpattern 129: names is not as general as Perl's. This is a consequence of the fact the PCRE 130: works internally just with numbers, using an external table to translate 131: between numbers and names. In particular, a pattern such as (?|(?<a>A)|(?<b)B), 132: where the two capturing parentheses have the same number but different names, 133: is not supported, and causes an error at compile time. If it were allowed, it 134: would not be possible to distinguish which parentheses matched, because both 135: names map to capturing subpattern number 1. To avoid this confusing situation, 136: an error is given at compile time. 137:  138:  139: 15. Perl recognizes comments in some places that PCRE does not, for example, 140: between the ( and ? at the start of a subpattern. If the /x modifier is set, 141: Perl allows white space between ( and ? (though current Perls warn that this is 142: deprecated) but PCRE never does, even if the PCRE_EXTENDED option is set. 143:  144:  145: 16. Perl, when in warning mode, gives warnings for character classes such as 146: [A-\d] or [a-[:digit:]]. It then treats the hyphens as literals. PCRE has no 147: warning features, so it gives an error in these cases because they are almost 148: certainly user mistakes. 149:  150:  151: 17. In PCRE, the upper/lower case character properties Lu and Ll are not 152: affected when case-independent matching is specified. For example, \p{Lu} 153: always matches an upper case letter. I think Perl has changed in this respect; 154: in the release at the time of writing (5.16), \p{Lu} and \p{Ll} match all 155: letters, regardless of case, when case independence is specified. 156:  157:  158: 18. PCRE provides some extensions to the Perl regular expression facilities. 159: Perl 5.10 includes new features that are not in earlier versions of Perl, some 160: of which (such as named parentheses) have been in PCRE for some time. This list 161: is with respect to Perl 5.10: 162:   163:   164: (a) Although lookbehind assertions in PCRE must match fixed length strings, 165: each alternative branch of a lookbehind assertion can match a different length 166: of string. Perl requires them all to have the same length. 167:   168:   169: (b) If PCRE_DOLLAR_ENDONLY is set and PCRE_MULTILINE is not set, the $ 170: meta-character matches only at the very end of the string. 171:   172:   173: (c) If PCRE_EXTRA is set, a backslash followed by a letter with no special 174: meaning is faulted. Otherwise, like Perl, the backslash is quietly ignored. 175: (Perl can be made to issue a warning.) 176:   177:   178: (d) If PCRE_UNGREEDY is set, the greediness of the repetition quantifiers is 179: inverted, that is, by default they are not greedy, but if followed by a 180: question mark they are. 181:   182:   183: (e) PCRE_ANCHORED can be used at matching time to force a pattern to be tried 184: only at the first matching position in the subject string. 185:   186:   187: (f) The PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, PCRE_NOTEMPTY_ATSTART, and 188: PCRE_NO_AUTO_CAPTURE options for pcre_exec() have no Perl equivalents. 189:   190:   191: (g) The \R escape sequence can be restricted to match only CR, LF, or CRLF 192: by the PCRE_BSR_ANYCRLF option. 193:   194:   195: (h) The callout facility is PCRE-specific. 196:   197:   198: (i) The partial matching facility is PCRE-specific. 199:   200:   201: (j) Patterns compiled by PCRE can be saved and re-used at a later time, even on 202: different hosts that have the other endianness. However, this does not apply to 203: optimized data created by the just-in-time compiler. 204:   205:   206: (k) The alternative matching functions (pcre_dfa_exec(), 207: pcre16_dfa_exec() and pcre32_dfa_exec(),) match in a different way 208: and are not Perl-compatible. 209:   210:   211: (l) PCRE recognizes some special sequences such as (*CR) at the start of 212: a pattern that set overall options that cannot be changed within the pattern. 213:  214:   215: AUTHOR 216:   217:  218: Philip Hazel 219:   220: University Computing Service 221:   222: Cambridge CB2 3QH, England. 223:   224:  225:   226: REVISION 227:   228:  229: Last updated: 10 November 2013 230:   231: Copyright © 1997-2013 University of Cambridge. 232:   233:  234: Return to the <a href="index.html">PCRE index page</a>. 235: 