Re: [pcre-dev] Typo about (?^)
On 2021-06-20 11:27, Philip Hazel wrote: A little bit further up from what you quoted, the docs say this: "The two "extended" options are not independent; unsetting either one cancels the effects of both of them." So (?-x) and (?-xx) are the same, and unset both (?x) and (?xx). I apologize for my carelessness. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Typo about (?^)
A little bit further up from what you quoted, the docs say this: "The two "extended" options are not independent; unsetting either one cancels the effects of both of them." So (?-x) and (?-xx) are the same, and unset both (?x) and (?xx). Regards, Philip On Sat, 19 Jun 2021 at 16:57, ND via Pcre-dev wrote: > PCRE docs say: > > > If the first character following (? is a circumflex, it causes all of > > the above options to be unset. > Thus, (?^) is equivalent to (?-imnsx). > > > There is "xx" option. So may be docs have a typo? > > - "all of the above options" -> "all of the above options but xx" > - or "(?^) is equivalent to (?-imnsx)" -> "(?^) is equivalent to > (?-imnsxxx)" > > -- > ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev > -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] Typo about (?^)
PCRE docs say: If the first character following (? is a circumflex, it causes all of the above options to be unset. > Thus, (?^) is equivalent to (?-imnsx). There is "xx" option. So may be docs have a typo? - "all of the above options" -> "all of the above options but xx" - or "(?^) is equivalent to (?-imnsx)" -> "(?^) is equivalent to (?-imnsxxx)" -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] Typo about \N ?
Pcrecompat man page says: 5. The following Perl escape sequences are not supported: \l, \u, \L, \U, and \N. In fact these are implemented by Perl's general string-handling and are not part of its pattern matching engine. If any of these are encountered by PCRE, an error is generated. \N semantics is described in pcrepattern man page and this escape sequence is not generate an error. Thanx. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
