./0040755000000000000000000000000007776057322007734 5ustar rootrootinstall/0040755000000000000000000000000007776057322011245 5ustar rootrootinstall/doinst.sh0100644000000000000000000000060207776057322013074 0ustar rootroot( cd usr/lib ; rm -rf libpcre.so ) ( cd usr/lib ; ln -sf libpcre.so.0.0.1 libpcre.so ) ( cd usr/lib ; rm -rf libpcre.so.0 ) ( cd usr/lib ; ln -sf libpcre.so.0.0.1 libpcre.so.0 ) ( cd usr/lib ; rm -rf libpcreposix.so ) ( cd usr/lib ; ln -sf libpcreposix.so.0.0.0 libpcreposix.so ) ( cd usr/lib ; rm -rf libpcreposix.so.0 ) ( cd usr/lib ; ln -sf libpcreposix.so.0.0.0 libpcreposix.so.0 ) install/slack-desc0100644000000000000000000000146307776057322013202 0ustar rootroot# HOW TO EDIT THIS FILE: # The "handy ruler" below makes it easier to edit a package description. Line # up the first '|' above the ':' following the base package name, and the '|' on # the right side marks the last column you can put a character in. You must make # exactly 11 lines for the formatting to be correct. It's also customary to # leave one space after the ':'. |-----handy-ruler------------------------------------------------------| pcre: pcre (Perl-compatible regular expression library) pcre: pcre: The PCRE library is a set of functions that implement regular pcre: expression pattern matching using the same syntax and semantics as pcre: Perl 5, with just a few differences (documented in the man page). pcre: pcre: The PCRE library is used by KDE's Konqueror browser. pcre: pcre: pcre: pcre: usr/0040755000000000000000000000000007776057322010410 5ustar rootrootusr/bin/0040755000000000000010000000000007776057302010744 5ustar rootbinusr/bin/pcre-config0100755000000000000010000000212007776057170013061 0ustar rootbin#!/bin/sh prefix=/usr exec_prefix=${prefix} exec_prefix_set=no usage="\ Usage: pcre-config [--prefix] [--exec-prefix] [--version] [--libs] [--libs-posix] [--cflags] [--cflags-posix]" if test $# -eq 0; then echo "${usage}" 1>&2 exit 1 fi while test $# -gt 0; do case "$1" in -*=*) optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` ;; *) optarg= ;; esac case $1 in --prefix=*) prefix=$optarg if test $exec_prefix_set = no ; then exec_prefix=$optarg fi ;; --prefix) echo $prefix ;; --exec-prefix=*) exec_prefix=$optarg exec_prefix_set=yes ;; --exec-prefix) echo $exec_prefix ;; --version) echo 4.4 ;; --cflags | --cflags-posix) if test ${prefix}/include != /usr/include ; then includes=-I${prefix}/include fi echo $includes ;; --libs-posix) echo -L${exec_prefix}/lib -lpcreposix -lpcre ;; --libs) echo -L${exec_prefix}/lib -lpcre ;; *) echo "${usage}" 1>&2 exit 1 ;; esac shift done usr/bin/pcregrep0100755000000000000010000002647407776057167012524 0ustar rootbinELF@ 4)4 (4@4@4@@ @@###@3@3&l@6l@6l$@$@$ dtP#@#@#ll/lib/ld.so.1GNU %&#"%    $! @6l@"@T@ @ $2@ D@H @ d@ @7@7@ (@ LL@ *@ 6c@7:@ $@ Dj7@L @ dS@ @  @ \@7=@7Po@7S@ J@7%@ 8+@@ $`@ Dn@ d^ @ r@  | libpcre.so.0_DYNAMIC_initpcre_versionpcre_compile_fini_GLOBAL_OFFSET_TABLE_pcre_study_Jv_RegisterClassespcre_exec__gmon_start__libc.so.6stdoutstrerrorfgetsputsmallocreaddirfprintfstdinopendirstrcmpsprintffclosestderr__ctype_b_locfwrite__xstat__errno_locationexitfopen_IO_stdin_used__libc_start_mainstrlenclosedir_edata__bss_start_endGLIBC_2.3GLIBC_2.1GLIBC_2.0 iit ii~ ii@7% @7 @7 @7 @7\ @7` @7d @7h @7l @7p @7t @7x @7| @7 @7 @7 @7 @7 @7 @7 @7 @7 @7 @7 @7 @7! @7# @7$ ol/PXXX %X0 M %xX0 M X@oxP XX@7P XX X@7\ XX X@7` XX X@7d XX X@7h$ XX X@7l0 XX X@7p< XX X@7tH XX Xw@7xT XX Xg@7|` XX XW@7l XX XG@7x XX X7@7 XX X'@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX X@7 XX Xw@7 Ч8A@X0`Ap`X`XPX X @<@@P@ $0@7@4X00PtXX/P X/tX00X@4@7LX  P X@4@ HX2(A@`P "8/(D XpT@8#X@4@ XP X@0@ dPX, " 8C0  >.t>.t .t !X@4@ XP X@o(@ @ @7@7@7@ @7@7@7@7@7@"@@@7@@7@@"xAP!("PP28"(" PPr"(8 XAX "X( "(A; 0XzY CAX X ʉApX0X hI[X,0X<cPhXPdP`` "(DX(? Xt("tXYDXY X /8" XP("8P2~X$/tCX8/t48"X33X(X0@@ @"N@"@.nPh.n$r.hh.h$N.V4.V$ .X(XP4X0@BX  XD( X0 X X( .ctX(P #X@𘘯X(X4X0,X@0X X 8 X0<BX ק.i.ltX(P XV0HX (ȧ.u(.u$.r .stXX.v .xtV0PX$X V0LoV@@ @#h@7@4@@@7@#n@@#B@ D@7@ d@7@#(@@ @ $@ @@ @ @7@"@ @ @"@ d@"@ @"`@ $@"l@7@ @7@4@7@ xxXP!YQ(  |PPRP1>8 |zX3X*0- t1C 81#>-'§3TРf9!XP Ct xYDX4(X0 P( X8?P "X /tX xYDX( X@8oX |XU p t9JX!PXh\h X"P X \X P Y ) pz `X\X0ˉ8JXPXxX,P X8X0P,0tlYD( xYU8 xXFXА_.X@ДP@8 |XМX@@X3[X!0XИX0 "t X XU^8 xYX@ДاX X%Y (P!觸XЈX@Ќ8X  BФXЀK'X0| XXPGX0ЄX X$ (&pXX@XPX0tXDX0@Ap` X "P% '8 XAXT "sX0X' XP\XPc$XgXdƧ CX0 A!0 ƧXh p t&9J[h X0\XP\X0AX0@ "PPX0P$0tXXPX`X0l@X X$ qXXP$X0`HdX  d8 XpX# X \X H XLX XRX0PX@CXX <8HXPX,9X P t#8 xX8 |X3X:0P0 X8H%X (XPX, XP( X X 8X?X`X0+ " _t8 |XXP$X3X XG0X0 X9X /tX *P (@H@3@3XP X X! X DX@𘘯,@3@3@LXX P˧X! ̧X X X@𘘿0@7@XXP XtX@oPXͧ%X0 M X@oxhelpdisplay this help and exitcountprint only a count of matching lines per FILEno-filenamesuppress the prefixing filename on outputignore-caseignore case distinctionsfiles-with-matchesprint only FILE names containing matchesline-numberprint line number with output linesrecursiverecursively scan sub-directoriesno-messagessuppress error messagesutf-8use UTF-8 modeversionprint version information and exitinvert-matchselect non-matching linesline-regexforce PATTERN to match only whole linesline-regexp%s:%d:%d pcregrep: Failed to open %s: %s %.512s%c%.128spcregrep: Failed to open directory %s: %s Usage: pcregrep [-Vcfhilnrsvx] [long-options] [pattern] [file1 file2 ...] Type `pcregrep --help' for more information. Usage: pcregrep [OPTION]... [PATTERN] [FILE1 FILE2 ...]Search for PATTERN in each FILE or standard input.PATTERN must be present if -f is not used.Example: pcregrep -i 'hello.*world' menu.h main.c Options:-%c, %s --%s%n%.*s%s -f or --file= Read patterns from instead of using a command line option. Trailing white space is removed; blanks lines are ignored. There is a maximum of %d patterns. With no FILE, read standard input. If fewer than two FILEs given, assume -h.Exit status is 0 if any matches, 1 if no matches, and 2 if trouble.pcregrep: Unknown option -%c pcregrep version %s using 3.0 14-Jan-2003PCRE version %s number %dpcregrep: Error while studying regex%s: %s pcregrep: Error in regex at offset %d: %s pcregrep: Error in regex number %d at offset %d: %s pcregrep: Too many patterns in file (max %d) pcregrep: malloc failed pcregrep: File name missing after -f file=pcregrep: Unknown option %s ; 4xPl<t$Hl@7H@@c@@h@@i@@$l@>@Rn@|@r@@s@@u@@V@@v@>@Lx@f@rx@@r | `@ XD R0@ &D NL@ ,rD Nl@ &D N(@ D ZD(@D R @\D ^ @\@D Z (@D ^(L@PD A x@<^D V@hD Z @H @L@D@@x  @7P @(@P o@oo@j@6l@@@ @ 0@ P@ p@ @ @ @ @ @ 0@ P@ p@ @ @ @ @ @ 0@ P@ p@ @ GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3.shstrtab.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version.gnu.version_r.rela.dyn.rela.plt.init.text.fini.rodata.eh_frame_hdr.data.eh_frame.dynamic.ctors.dtors.jcr.got.sbss.bss.comment @ @$$ !@DD4' @xx`/@7o@jjLDo@@S@0 ]@((   g@HH\b@ m@ s@LL8y@@##l@3#@4$@6l&l@7<'<@7D'D@7L'L@7P'Pp@7'@7'<'p(0usr/bin/pcretest0100755000000000000010000006075007776057170012533 0ustar rootbinELF@4]4 (4@4@4@@ @@W@W@W@@g@@g@,dZ@j@j$@$@$ dtPV@V@Vll/lib/ld.so.1GNU %3.- %12(,'+ )&0#/$*  "!@ T"@j@ t@ T+@ V@ %@ @ ,@ 49@  ?@ T@ tW@ j@ w@ :@ll@lp@ L+@ 4@ 4@ Tl@ t@ 68@ll @ @ `t@ @j@F@ |@4 @T1@ll@k@tD@l@@J@lt@lx@8@F|@>@@4n @T@t:7@ A P@libpcre.so.0pcre_copy_substring_DYNAMICpcre_fullinfo_initpcre_get_substring_listpcre_get_substringpcre_versionpcre_free_substringpcre_mallocpcre_compilepcre_config_fini_GLOBAL_OFFSET_TABLE_pcre_get_stringnumberpcre_studypcre_calloutpcre_maketables_Jv_RegisterClassespcre_free_substring_listpcre_exec__gmon_start__pcre_infolibpcreposix.so.0regcompregexecregerrorregfreelibc.so.6stdoutfgetsfflush__ctype_tolower_locfprintfstdinsetlocalefputc__ctype_b_locfwriteexitfopen_IO_stdin_used__libc_start_mainstrlenclockfputs_edata__bss_start_endGLIBC_2.1GLIBC_2.0GLIBC_2.3 iiI iiS ii]@lh1 @ll @lp @lt& @lx' @k @k @k @k @k @k @k @k @k @k @l @l @l @l  @l @l @l @l @l  @l$ @l( @l, @l0 @l4 @l8 @l<" @l@$ @lD% @lH( @lL* @lP+ @lT, @lX. @l\/ @l`0 @ld2 o`PXXX %tX0 M %:X0 M X@oxP XX@k XX X@k XX X@k XX X@k XX X@k$ XX X@k0 XX X@k< XX X@kH XX Xw@kT XX Xg@k` XX XW@kl XX XG@lx XX X7@l XX X'@l XX X@l XX X@l XX X@l XX X@l XX X@l XX X@l XX X@l$ XX X@l( XX X@l, XX X@l0 XX Xw@l4 XX Xg@l8 XX XW@l<, XX XG@l@8 XX X7@lDD XX X'@lHP XX X@lL\ XX X@lPh XX X@lTt XX X@lX XX X@l\ XX X@l` XX X@ld Ч8A@X0`Ap`X`XPX X @E0@E@!@ 0@l|@gHX00PtXX/P X/tX00X@4@kX  P X@$@T@ T@M@ @h@h@M?PC 0D!%X <0X A#@ X,: (X@𘘟X *X0L T XXC90XI@I@TY@$)CTJ@Z&$ *X0X L )*X0o\@M"@ @M(@M8@gL@MD@g@ML@4@M@@K@@K@M@ @ T@K@M@M@T@M@M@M@M@K@K@M@M@K@K@K@K@K@G@L@FK-$986xs  Rqrz` X` (!PP `XKGX0( C 2XSUPДh1Z^HC@@CAX0( X(C LЧHC@@CAX0 ( PXАX%XSPXX0(XEX X X8HCX  X@o(#H C@X0$XXR(X C X@X8( CQ@X@EF qXClX0(F ᧪fX(:(X@` 4X P HC@40X AS@P X0T(X X0XX X8HX 8 X(;:X@`( X@b8({ (,8 HC@@CAXX0D( C !Рtr8(? jX P HC@40X A#@ X0TX( HC@X@8X$X< BX0XX P HC@40X AS@P0X0\X( %X@(,8 HC@@CAXX0D( C !Фt(?8X@X0`X X 88HX %HC@@X8X$X< X(;:(X@` bCXPXX0H(XAP . X X L8HX HC@@CAX0D( C !ТX X l8HX 9o̧bD](8)C1 Dɧ$D>(X,CQ 觞-]X0P 90X AS@PX@)8 ɧ$ C !Ъ!ЬzX@|XX0t( CA($*U Ю$ XЈX"T@И@X8hX$X< 8X@C0C Cc@CHC@@8(C0C QCRt$XX0Ѐ( CвTИX@hC Ca@X@(?8 CXX0Є( X@xÇyX(:(H ÇtC ^XP@8(- :(H X@(-8 -$] XP <0X A#@ XP@,8 X(X0pL (\8 XP(X0pI X@(\8 §ȰhC``CaTЦX@8(^ zHC@@CAXX0d( X@CC@T0И0X HC@@CXS AX0,ɧ(# XXX0hCPXBHC@@CAY@М (# X0,X 48HXX XSPXX0Ќ(XEۧXSX P8C00C1XE X0X ,Ð@TsXPCˉ X A  X HK90AQ PC)X@Pp|P4@F@FBS(XY@*U  X4U $DDR"2?BP@Z620X  C BP, @F@F?8C0 H#! JNN[DTNP$ XTPTT2#P PC.TZ P!DXY  U J$,P $*  ((P0o@l@@T@ T@M@ @Mç3P0XpX`X/t7 HC@40X P@`A#@ $X : ᧊$(X@o*X0 槊XA0`+ "!$X`$ 90X A#@ )t IAPd*X0 Zd$@l@l@l@N @ @N2@N,@$@ T@M@4@M@M"@M@l@l@lXX0XV0P&XX0t X(X $8HZ XX0JX XX0X 1!J XX0X 1!J X :( X/X8HX ,XPX( XX ( X0 XXp (^X0  ( X0 XX@ (^X0 XX ( X0 X8/$P0 t#X8H$X@|X0@K@V@VV@V@VR@Vr@V@V@T@T@T@T@U*@U@U@P@M @@Tt@Nb@lp@!@Nd@ @l@Tl@ @ @ @T@TB@4@N@N@Nv@l@ @T @@T*@H@ t@4@PX@ @ @t@S@S@ 4@ T@S@l@ML@@!H@@S@Pt@P@P@Q@QR@Qt@Q@Q@S@R$@Q@Q@Q@Q@Q@Q@Q@R@R@R@Sr@SN@S>@S@RB@S*@S@RX@R@@R@R@R@Rl@R@R@R@R@lx@X@l@l@l@l@l@PP@ t@|@@O@I@ @N@N,@$@N@@O@N@O@N2@ T@O@Ov@ @OZ@OL@ @ T@O.@O@O @t@O@O@@N \nO@@@jA.B?x!-XhX(u0P P (( P ,PX PX8-P0 (P P P P $X-XX, "P  3$맮ɉXtX0|X, X"P XЀX Є XXPЌBX0ЈX  XАXXPP0PP4PPXYPP8PP@PPDH PPLPPPTPPXXИX (8u0X@ "?X Y XX@МX (X0 XX0Р<(X  XФ X X@<C@ˉA\  P X0<:P0<tX@$DXX@( X0 (X@Иo X<P+է>-ç>!Q>*tX<(P

@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@(@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@@@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@@@B>@B>@B>@B>@B>@B>@A @B>@A@B>@B>@A*@A:@B>@AJ@B>@AV@B>@B>@Ab@A@A@B>@A@B>@B>@B@B>@B@B>@B>@B@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@B>@(|@B>@B&@B>@B>@B>@B.@B>@B>@B>@B>@B>@B6@B>@B>@B>@B>@B`@1@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@1@1@1@1@1@1@1@1@*\@*\@*\@*\@*\@*\@*\@2\@*\@2p@2@2@*\@*\@*\@5@*\@*\@*\@*\@6t@6@6@6@*\@*\@*\@*\@*\@*\@*\@*\@*\@*\@7N@*\@*\@*\@*\@*\@*\@1@7V@*\@*\@7^@7f@*\@*\@*\@*\@*\@*\@*\@7n@*\@*\@*\@7v@*\@7~@*\@7@*\@7]%s{%d,}{%d,%d} (neg) \%d%3d %s %s %d Cond recurse %sEnd\A\G\B\b\D\d\S\s\W\wAnyAnybyte\Z\zOpt^$chars**?++????classnclassxclassRefRecurseCalloutAltKetKetRmaxKetRminAssertAssert notAssertBAssertB notReverseOnceCondCond refBrazeroBraminzeroBranumberBra\x%02x\x{%x}%3d %3d Bra extra %3d Bra %d %s ------------------------------------------------------------------ %.2x %s [^%c] [^\x%02x] [^%c]{ [^\x%02x]{ %s{0, [\x{%02x}%n--->Callout data = %d Callout %d: last capture = %d %2d: %2d: Error %d from pcre_fullinfo(%d) wPCRE version %s ** Unexpected EOF C > ** Expression too long - missing delimiter? 0+ No match: POSIX code %d: %s Minimum match limit = %d %2dL %s string list not terminated by NULL get substring list failed %d %2dG %s (%d) get substring %d failed %d %2dC %s (%d) copy substring %d failed %d Error %d No match Matched, but too many substrings Execute time %.3f milliseconds no parentheses with name "%s" ** Failed to get %d bytes of memory for offsets vector data> Failed: POSIX code %d: %s Count disagreement: pcre_fullinfo=%d pcre_info=%d First char disagreement: pcre_fullinfo=%d pcre_info=%d Options disagreement: pcre_fullinfo=%ld pcre_info=%d Size disagreement: pcre_fullinfo=%d call to malloc for %d Capturing subpattern count = %d Max back reference = %d Named capturing subpatterns: %s %*s%3d anchored caseless extended multiline dotall dollar_endonly extra ungreedy utf8 no_utf8_checkOptions:%s%s%s%s%s%s%s%s%s%s First char = '%c'%s Need char = '%c'%s No starting character set Starting character set: %c \x%02x Study returned NULL Failed to study: %s Study time %.3f milliseconds Need char = %d%s (caseless)No need char First char = %d%s No first char First char at start or follows \n Case state changes No options Error %d from pcre_info() Memory allocation (code space): %d Failed: %s at offset %d Compile time %.3f milliseconds ** Failed to set locale "%s" ** Unknown option '%c' ** Delimiter must not be alphameric or \ re> ** Failed to open %s ** Unknown or malformed option %s Usage: pcretest [-d] [-i] [-o ] [-p] [-s] [-t] [ []] -C show PCRE compile-time options and exit -d debug: show compiled code; implies -i -i show information about compiled pattern -o set size of offsets vector to -p use POSIX interface -s output store information -t time compilation and executionPCRE version %s Compiled with %sUTF-8 support LF Newline character is %s Internal link size = %d POSIX malloc threshold = %d Default match limit = %d CRNo ;P d ĨDPDŽ4@\tx\@k!!@L@L @L@L@L@L@L @L$@L(@L,@L0@L4@L8@L@@LD@LH@LL@LN@LP@L@LV@LX@L\@L^@Lb@Ld@M@M@M@LV@LX@L\@L^@Lb@Ld@M@M@M@LV@LX@L\@L^@Lb@Ld@M@M@M@LV@LX@L\@L^@Lb@Ld@M@M@Lh@Ln@Lv@L~@L@L@L@L@L@L@L@L@L@L@L@L@L@L@L@L@M@M | ` @D j(8@ D $d@D N@|D @ D (@$2D f$@XD V @!2D V(@!HTD Z(H@!#D  t@E0^D V@EhD ZZ @ @F@@D@@ g @k@ (@ o@oo@D@j@ `@ @ @ @ @ @ @ @@ `@ @ @ @ @ @ @ @@ `@ @ @ @ @@ @@@`@@@@@@ @@@`@@@GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3.shstrtab.interp.note.ABI-tag.hash.dynsym.dynstr.gnu.version.gnu.version_r.rela.dyn.rela.plt.init.text.fini.rodata.eh_frame_hdr.data.eh_frame.dynamic.ctors.dtors.jcr.got.sbss.bss.comment @ @$$ !@DDh' @0/@g7o@DDfDo@@S@< ]@ ( (  g@ \b@ 4 4m@6ls@F@F@8y@FxFxZ@VVl@g@W@@i(Y(@jZ@k[@k[@k[@k[@ll\l@ll\l8\lp\usr/doc/0040755000000000000000000000000007776057301011152 5ustar rootrootusr/doc/pcre-4.4/0040755000000000000000000000000007776057301012406 5ustar rootrootusr/doc/pcre-4.4/AUTHORS0100644000000000000000000000026307721121073013440 0ustar rootrootWritten by: Philip Hazel University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714. Copyright (c) 1997-2001 University of Cambridge usr/doc/pcre-4.4/COPYING0100644000000000000000000000425207721121073013425 0ustar rootrootPCRE LICENCE ------------ PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. Written by: Philip Hazel University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714. Copyright (c) 1997-2001 University of Cambridge Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software that you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. However, this condition is not intended to apply to whole chains of software. If package A includes PCRE, it must acknowledge it, but if package B is software that includes package A, the condition is not imposed on package B (unless it uses PCRE independently). 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), or Lesser General Purpose Licence (LGPL), then the terms of that licence shall supersede any condition above with which it is incompatible. The documentation for PCRE, supplied in the "doc" directory, is distributed under the same terms as the software itself. End usr/doc/pcre-4.4/ChangeLog0100644000000000000000000016443307721121073014154 0ustar rootrootChangeLog for PCRE ------------------ Version 4.4 13-Aug-03 --------------------- 1. In UTF-8 mode, a character class containing characters with values between 127 and 255 was not handled correctly if the compiled pattern was studied. In fixing this, I have also improved the studying algorithm for such classes (slightly). 2. Three internal functions had redundant arguments passed to them. Removal might give a very teeny performance improvement. 3. Documentation bug: the value of the capture_top field in a callout is *one more than* the number of the hightest numbered captured substring. 4. The Makefile linked pcretest and pcregrep with -lpcre, which could result in incorrectly linking with a previously installed version. They now link explicitly with libpcre.la. 5. configure.in no longer needs to recognize Cygwin specially. 6. A problem in pcre.in for Windows platforms is fixed. 7. If a pattern was successfully studied, and the -d (or /D) flag was given to pcretest, it used to include the size of the study block as part of its output. Unfortunately, the structure contains a field that has a different size on different hardware architectures. This meant that the tests that showed this size failed. As the block is currently always of a fixed size, this information isn't actually particularly useful in pcretest output, so I have just removed it. 8. Three pre-processor statements accidentally did not start in column 1. Sadly, there are *still* compilers around that complain, even though standard C has not required this for well over a decade. Sigh. 9. In pcretest, the code for checking callouts passed small integers in the callout_data field, which is a void * field. However, some picky compilers complained about the casts involved for this on 64-bit systems. Now pcretest passes the address of the small integer instead, which should get rid of the warnings. 10. By default, when in UTF-8 mode, PCRE now checks for valid UTF-8 strings at both compile and run time, and gives an error if an invalid UTF-8 sequence is found. There is a option for disabling this check in cases where the string is known to be correct and/or the maximum performance is wanted. 11. In response to a bug report, I changed one line in Makefile.in from -Wl,--out-implib,.libs/lib@WIN_PREFIX@pcreposix.dll.a \ to -Wl,--out-implib,.libs/@WIN_PREFIX@libpcreposix.dll.a \ to look similar to other lines, but I have no way of telling whether this is the right thing to do, as I do not use Windows. No doubt I'll get told if it's wrong... Version 4.3 21-May-03 --------------------- 1. Two instances of @WIN_PREFIX@ omitted from the Windows targets in the Makefile. 2. Some refactoring to improve the quality of the code: (i) The utf8_table... variables are now declared "const". (ii) The code for \cx, which used the "case flipping" table to upper case lower case letters, now just substracts 32. This is ASCII-specific, but the whole concept of \cx is ASCII-specific, so it seems reasonable. (iii) PCRE was using its character types table to recognize decimal and hexadecimal digits in the pattern. This is silly, because it handles only 0-9, a-f, and A-F, but the character types table is locale- specific, which means strange things might happen. A private table is now used for this - though it costs 256 bytes, a table is much faster than multiple explicit tests. Of course, the standard character types table is still used for matching digits in subject strings against \d. (iv) Strictly, the identifier ESC_t is reserved by POSIX (all identifiers ending in _t are). So I've renamed it as ESC_tee. 3. The first argument for regexec() in the POSIX wrapper should have been defined as "const". 4. Changed pcretest to use malloc() for its buffers so that they can be Electric Fenced for debugging. 5. There were several places in the code where, in UTF-8 mode, PCRE would try to read one or more bytes before the start of the subject string. Often this had no effect on PCRE's behaviour, but in some circumstances it could provoke a segmentation fault. 6. A lookbehind at the start of a pattern in UTF-8 mode could also cause PCRE to try to read one or more bytes before the start of the subject string. 7. A lookbehind in a pattern matched in non-UTF-8 mode on a PCRE compiled with UTF-8 support could misbehave in various ways if the subject string contained bytes with the 0x80 bit set and the 0x40 bit unset in a lookbehind area. (PCRE was not checking for the UTF-8 mode flag, and trying to move back over UTF-8 characters.) Version 4.2 14-Apr-03 --------------------- 1. Typo "#if SUPPORT_UTF8" instead of "#ifdef SUPPORT_UTF8" fixed. 2. Changes to the building process, supplied by Ronald Landheer-Cieslak [ON_WINDOWS]: new variable, "#" on non-Windows platforms [NOT_ON_WINDOWS]: new variable, "#" on Windows platforms [WIN_PREFIX]: new variable, "cyg" for Cygwin * Makefile.in: use autoconf substitution for OBJEXT, EXEEXT, BUILD_OBJEXT and BUILD_EXEEXT Note: automatic setting of the BUILD variables is not yet working set CPPFLAGS and BUILD_CPPFLAGS (but don't use yet) - should be used at compile-time but not at link-time [LINK]: use for linking executables only make different versions for Windows and non-Windows [LINKLIB]: new variable, copy of UNIX-style LINK, used for linking libraries [LINK_FOR_BUILD]: new variable [OBJEXT]: use throughout [EXEEXT]: use throughout : new target : new target : use native compiler : use native linker : handle Windows platform correctly : ditto : ditto copy DLL to top builddir before testing As part of these changes, -no-undefined was removed again. This was reported to give trouble on HP-UX 11.0, so getting rid of it seems like a good idea in any case. 3. Some tidies to get rid of compiler warnings: . In the match_data structure, match_limit was an unsigned long int, whereas match_call_count was an int. I've made them both unsigned long ints. . In pcretest the fact that a const uschar * doesn't automatically cast to a void * provoked a warning. . Turning on some more compiler warnings threw up some "shadow" variables and a few more missing casts. 4. If PCRE was complied with UTF-8 support, but called without the PCRE_UTF8 option, a class that contained a single character with a value between 128 and 255 (e.g. /[\xFF]/) caused PCRE to crash. 5. If PCRE was compiled with UTF-8 support, but called without the PCRE_UTF8 option, a class that contained several characters, but with at least one whose value was between 128 and 255 caused PCRE to crash. Version 4.1 12-Mar-03 --------------------- 1. Compiling with gcc -pedantic found a couple of places where casts were needed, and a string in dftables.c that was longer than standard compilers are required to support. 2. Compiling with Sun's compiler found a few more places where the code could be tidied up in order to avoid warnings. 3. The variables for cross-compiling were called HOST_CC and HOST_CFLAGS; the first of these names is deprecated in the latest Autoconf in favour of the name CC_FOR_BUILD, because "host" is typically used to mean the system on which the compiled code will be run. I can't find a reference for HOST_CFLAGS, but by analogy I have changed it to CFLAGS_FOR_BUILD. 4. Added -no-undefined to the linking command in the Makefile, because this is apparently helpful for Windows. To make it work, also added "-L. -lpcre" to the linking step for the pcreposix library. 5. PCRE was failing to diagnose the case of two named groups with the same name. 6. A problem with one of PCRE's optimizations was discovered. PCRE remembers a literal character that is needed in the subject for a match, and scans along to ensure that it is present before embarking on the full matching process. This saves time in cases of nested unlimited repeats that are never going to match. Problem: the scan can take a lot of time if the subject is very long (e.g. megabytes), thus penalizing straightforward matches. It is now done only if the amount of subject to be scanned is less than 1000 bytes. 7. A lesser problem with the same optimization is that it was recording the first character of an anchored pattern as "needed", thus provoking a search right along the subject, even when the first match of the pattern was going to fail. The "needed" character is now not set for anchored patterns, unless it follows something in the pattern that is of non-fixed length. Thus, it still fulfils its original purpose of finding quick non-matches in cases of nested unlimited repeats, but isn't used for simple anchored patterns such as /^abc/. Version 4.0 17-Feb-03 --------------------- 1. If a comment in an extended regex that started immediately after a meta-item extended to the end of string, PCRE compiled incorrect data. This could lead to all kinds of weird effects. Example: /#/ was bad; /()#/ was bad; /a#/ was not. 2. Moved to autoconf 2.53 and libtool 1.4.2. 3. Perl 5.8 no longer needs "use utf8" for doing UTF-8 things. Consequently, the special perltest8 script is no longer needed - all the tests can be run from a single perltest script. 4. From 5.004, Perl has not included the VT character (0x0b) in the set defined by \s. It has now been removed in PCRE. This means it isn't recognized as whitespace in /x regexes too, which is the same as Perl. Note that the POSIX class [:space:] *does* include VT, thereby creating a mess. 5. Added the class [:blank:] (a GNU extension from Perl 5.8) to match only space and tab. 6. Perl 5.005 was a long time ago. It's time to amalgamate the tests that use its new features into the main test script, reducing the number of scripts. 7. Perl 5.8 has changed the meaning of patterns like /a(?i)b/. Earlier versions were backward compatible, and made the (?i) apply to the whole pattern, as if /i were given. Now it behaves more logically, and applies the option setting only to what follows. PCRE has been changed to follow suit. However, if it finds options settings right at the start of the pattern, it extracts them into the global options, as before. Thus, they show up in the info data. 8. Added support for the \Q...\E escape sequence. Characters in between are treated as literals. This is slightly different from Perl in that $ and @ are also handled as literals inside the quotes. In Perl, they will cause variable interpolation. Note the following examples: Pattern PCRE matches Perl matches \Qabc$xyz\E abc$xyz abc followed by the contents of $xyz \Qabc\$xyz\E abc\$xyz abc\$xyz \Qabc\E\$\Qxyz\E abc$xyz abc$xyz For compatibility with Perl, \Q...\E sequences are recognized inside character classes as well as outside them. 9. Re-organized 3 code statements in pcretest to avoid "overflow in floating-point constant arithmetic" warnings from a Microsoft compiler. Added a (size_t) cast to one statement in pcretest and one in pcreposix to avoid signed/unsigned warnings. 10. SunOS4 doesn't have strtoul(). This was used only for unpicking the -o option for pcretest, so I've replaced it by a simple function that does just that job. 11. pcregrep was ending with code 0 instead of 2 for the commands "pcregrep" or "pcregrep -". 12. Added "possessive quantifiers" ?+, *+, ++, and {,}+ which come from Sun's Java package. This provides some syntactic sugar for simple cases of what my documentation calls "once-only subpatterns". A pattern such as x*+ is the same as (?>x*). In other words, if what is inside (?>...) is just a single repeated item, you can use this simplified notation. Note that only makes sense with greedy quantifiers. Consequently, the use of the possessive quantifier forces greediness, whatever the setting of the PCRE_UNGREEDY option. 13. A change of greediness default within a pattern was not taking effect at the current level for patterns like /(b+(?U)a+)/. It did apply to parenthesized subpatterns that followed. Patterns like /b+(?U)a+/ worked because the option was abstracted outside. 14. PCRE now supports the \G assertion. It is true when the current matching position is at the start point of the match. This differs from \A when the starting offset is non-zero. Used with the /g option of pcretest (or similar code), it works in the same way as it does for Perl's /g option. If all alternatives of a regex begin with \G, the expression is anchored to the start match position, and the "anchored" flag is set in the compiled expression. 15. Some bugs concerning the handling of certain option changes within patterns have been fixed. These applied to options other than (?ims). For example, "a(?x: b c )d" did not match "XabcdY" but did match "Xa b c dY". It should have been the other way round. Some of this was related to change 7 above. 16. PCRE now gives errors for /[.x.]/ and /[=x=]/ as unsupported POSIX features, as Perl does. Previously, PCRE gave the warnings only for /[[.x.]]/ and /[[=x=]]/. PCRE now also gives an error for /[:name:]/ because it supports POSIX classes only within a class (e.g. /[[:alpha:]]/). 17. Added support for Perl's \C escape. This matches one byte, even in UTF8 mode. Unlike ".", it always matches newline, whatever the setting of PCRE_DOTALL. However, PCRE does not permit \C to appear in lookbehind assertions. Perl allows it, but it doesn't (in general) work because it can't calculate the length of the lookbehind. At least, that's the case for Perl 5.8.0 - I've been told they are going to document that it doesn't work in future. 18. Added an error diagnosis for escapes that PCRE does not support: these are \L, \l, \N, \P, \p, \U, \u, and \X. 19. Although correctly diagnosing a missing ']' in a character class, PCRE was reading past the end of the pattern in cases such as /[abcd/. 20. PCRE was getting more memory than necessary for patterns with classes that contained both POSIX named classes and other characters, e.g. /[[:space:]abc/. 21. Added some code, conditional on #ifdef VPCOMPAT, to make life easier for compiling PCRE for use with Virtual Pascal. 22. Small fix to the Makefile to make it work properly if the build is done outside the source tree. 23. Added a new extension: a condition to go with recursion. If a conditional subpattern starts with (?(R) the "true" branch is used if recursion has happened, whereas the "false" branch is used only at the top level. 24. When there was a very long string of literal characters (over 255 bytes without UTF support, over 250 bytes with UTF support), the computation of how much memory was required could be incorrect, leading to segfaults or other strange effects. 25. PCRE was incorrectly assuming anchoring (either to start of subject or to start of line for a non-DOTALL pattern) when a pattern started with (.*) and there was a subsequent back reference to those brackets. This meant that, for example, /(.*)\d+\1/ failed to match "abc123bc". Unfortunately, it isn't possible to check for precisely this case. All we can do is abandon the optimization if .* occurs inside capturing brackets when there are any back references whatsoever. (See below for a better fix that came later.) 26. The handling of the optimization for finding the first character of a non-anchored pattern, and for finding a character that is required later in the match were failing in some cases. This didn't break the matching; it just failed to optimize when it could. The way this is done has been re-implemented. 27. Fixed typo in error message for invalid (?R item (it said "(?p"). 28. Added a new feature that provides some of the functionality that Perl provides with (?{...}). The facility is termed a "callout". The way it is done in PCRE is for the caller to provide an optional function, by setting pcre_callout to its entry point. Like pcre_malloc and pcre_free, this is a global variable. By default it is unset, which disables all calling out. To get the function called, the regex must include (?C) at appropriate points. This is, in fact, equivalent to (?C0), and any number <= 255 may be given with (?C). This provides a means of identifying different callout points. When PCRE reaches such a point in the regex, if pcre_callout has been set, the external function is called. It is provided with data in a structure called pcre_callout_block, which is defined in pcre.h. If the function returns 0, matching continues; if it returns a non-zero value, the match at the current point fails. However, backtracking will occur if possible. [This was changed later and other features added - see item 49 below.] 29. pcretest is upgraded to test the callout functionality. It provides a callout function that displays information. By default, it shows the start of the match and the current position in the text. There are some new data escapes to vary what happens: \C+ in addition, show current contents of captured substrings \C- do not supply a callout function \C!n return 1 when callout number n is reached \C!n!m return 1 when callout number n is reached for the mth time 30. If pcregrep was called with the -l option and just a single file name, it output "" if a match was found, instead of the file name. 31. Improve the efficiency of the POSIX API to PCRE. If the number of capturing slots is less than POSIX_MALLOC_THRESHOLD, use a block on the stack to pass to pcre_exec(). This saves a malloc/free per call. The default value of POSIX_MALLOC_THRESHOLD is 10; it can be changed by --with-posix-malloc-threshold when configuring. 32. The default maximum size of a compiled pattern is 64K. There have been a few cases of people hitting this limit. The code now uses macros to handle the storing of links as offsets within the compiled pattern. It defaults to 2-byte links, but this can be changed to 3 or 4 bytes by --with-link-size when configuring. Tests 2 and 5 work only with 2-byte links because they output debugging information about compiled patterns. 33. Internal code re-arrangements: (a) Moved the debugging function for printing out a compiled regex into its own source file (printint.c) and used #include to pull it into pcretest.c and, when DEBUG is defined, into pcre.c, instead of having two separate copies. (b) Defined the list of op-code names for debugging as a macro in internal.h so that it is next to the definition of the opcodes. (c) Defined a table of op-code lengths for simpler skipping along compiled code. This is again a macro in internal.h so that it is next to the definition of the opcodes. 34. Added support for recursive calls to individual subpatterns, along the lines of Robin Houston's patch (but implemented somewhat differently). 35. Further mods to the Makefile to help Win32. Also, added code to pcregrep to allow it to read and process whole directories in Win32. This code was contributed by Lionel Fourquaux; it has not been tested by me. 36. Added support for named subpatterns. The Python syntax (?P...) is used to name a group. Names consist of alphanumerics and underscores, and must be unique. Back references use the syntax (?P=name) and recursive calls use (?P>name) which is a PCRE extension to the Python extension. Groups still have numbers. The function pcre_fullinfo() can be used after compilation to extract a name/number map. There are three relevant calls: PCRE_INFO_NAMEENTRYSIZE yields the size of each entry in the map PCRE_INFO_NAMECOUNT yields the number of entries PCRE_INFO_NAMETABLE yields a pointer to the map. The map is a vector of fixed-size entries. The size of each entry depends on the length of the longest name used. The first two bytes of each entry are the group number, most significant byte first. There follows the corresponding name, zero terminated. The names are in alphabetical order. 37. Make the maximum literal string in the compiled code 250 for the non-UTF-8 case instead of 255. Making it the same both with and without UTF-8 support means that the same test output works with both. 38. There was a case of malloc(0) in the POSIX testing code in pcretest. Avoid calling malloc() with a zero argument. 39. Change 25 above had to resort to a heavy-handed test for the .* anchoring optimization. I've improved things by keeping a bitmap of backreferences with numbers 1-31 so that if .* occurs inside capturing brackets that are not in fact referenced, the optimization can be applied. It is unlikely that a relevant occurrence of .* (i.e. one which might indicate anchoring or forcing the match to follow \n) will appear inside brackets with a number greater than 31, but if it does, any back reference > 31 suppresses the optimization. 40. Added a new compile-time option PCRE_NO_AUTO_CAPTURE. This has the effect of disabling numbered capturing parentheses. Any opening parenthesis that is not followed by ? behaves as if it were followed by ?: but named parentheses can still be used for capturing (and they will acquire numbers in the usual way). 41. Redesigned the return codes from the match() function into yes/no/error so that errors can be passed back from deep inside the nested calls. A malloc failure while inside a recursive subpattern call now causes the PCRE_ERROR_NOMEMORY return instead of quietly going wrong. 42. It is now possible to set a limit on the number of times the match() function is called in a call to pcre_exec(). This facility makes it possible to limit the amount of recursion and backtracking, though not in a directly obvious way, because the match() function is used in a number of different circumstances. The count starts from zero for each position in the subject string (for non-anchored patterns). The default limit is, for compatibility, a large number, namely 10 000 000. You can change this in two ways: (a) When configuring PCRE before making, you can use --with-match-limit=n to set a default value for the compiled library. (b) For each call to pcre_exec(), you can pass a pcre_extra block in which a different value is set. See 45 below. If the limit is exceeded, pcre_exec() returns PCRE_ERROR_MATCHLIMIT. 43. Added a new function pcre_config(int, void *) to enable run-time extraction of things that can be changed at compile time. The first argument specifies what is wanted and the second points to where the information is to be placed. The current list of available information is: PCRE_CONFIG_UTF8 The output is an integer that is set to one if UTF-8 support is available; otherwise it is set to zero. PCRE_CONFIG_NEWLINE The output is an integer that it set to the value of the code that is used for newline. It is either LF (10) or CR (13). PCRE_CONFIG_LINK_SIZE The output is an integer that contains the number of bytes used for internal linkage in compiled expressions. The value is 2, 3, or 4. See item 32 above. PCRE_CONFIG_POSIX_MALLOC_THRESHOLD The output is an integer that contains the threshold above which the POSIX interface uses malloc() for output vectors. See item 31 above. PCRE_CONFIG_MATCH_LIMIT The output is an unsigned integer that contains the default limit of the number of match() calls in a pcre_exec() execution. See 42 above. 44. pcretest has been upgraded by the addition of the -C option. This causes it to extract all the available output from the new pcre_config() function, and to output it. The program then exits immediately. 45. A need has arisen to pass over additional data with calls to pcre_exec() in order to support additional features. One way would have been to define pcre_exec2() (for example) with extra arguments, but this would not have been extensible, and would also have required all calls to the original function to be mapped to the new one. Instead, I have chosen to extend the mechanism that is used for passing in "extra" data from pcre_study(). The pcre_extra structure is now exposed and defined in pcre.h. It currently contains the following fields: flags a bitmap indicating which of the following fields are set study_data opaque data from pcre_study() match_limit a way of specifying a limit on match() calls for a specific call to pcre_exec() callout_data data for callouts (see 49 below) The flag bits are also defined in pcre.h, and are PCRE_EXTRA_STUDY_DATA PCRE_EXTRA_MATCH_LIMIT PCRE_EXTRA_CALLOUT_DATA The pcre_study() function now returns one of these new pcre_extra blocks, with the actual study data pointed to by the study_data field, and the PCRE_EXTRA_STUDY_DATA flag set. This can be passed directly to pcre_exec() as before. That is, this change is entirely upwards-compatible and requires no change to existing code. If you want to pass in additional data to pcre_exec(), you can either place it in a pcre_extra block provided by pcre_study(), or create your own pcre_extra block. 46. pcretest has been extended to test the PCRE_EXTRA_MATCH_LIMIT feature. If a data string contains the escape sequence \M, pcretest calls pcre_exec() several times with different match limits, until it finds the minimum value needed for pcre_exec() to complete. The value is then output. This can be instructive; for most simple matches the number is quite small, but for pathological cases it gets very large very quickly. 47. There's a new option for pcre_fullinfo() called PCRE_INFO_STUDYSIZE. It returns the size of the data block pointed to by the study_data field in a pcre_extra block, that is, the value that was passed as the argument to pcre_malloc() when PCRE was getting memory in which to place the information created by pcre_study(). The fourth argument should point to a size_t variable. pcretest has been extended so that this information is shown after a successful pcre_study() call when information about the compiled regex is being displayed. 48. Cosmetic change to Makefile: there's no need to have / after $(DESTDIR) because what follows is always an absolute path. (Later: it turns out that this is more than cosmetic for MinGW, because it doesn't like empty path components.) 49. Some changes have been made to the callout feature (see 28 above): (i) A callout function now has three choices for what it returns: 0 => success, carry on matching > 0 => failure at this point, but backtrack if possible < 0 => serious error, return this value from pcre_exec() Negative values should normally be chosen from the set of PCRE_ERROR_xxx values. In particular, returning PCRE_ERROR_NOMATCH forces a standard "match failed" error. The error number PCRE_ERROR_CALLOUT is reserved for use by callout functions. It will never be used by PCRE itself. (ii) The pcre_extra structure (see 45 above) has a void * field called callout_data, with corresponding flag bit PCRE_EXTRA_CALLOUT_DATA. The pcre_callout_block structure has a field of the same name. The contents of the field passed in the pcre_extra structure are passed to the callout function in the corresponding field in the callout block. This makes it easier to use the same callout-containing regex from multiple threads. For testing, the pcretest program has a new data escape \C*n pass the number n (may be negative) as callout_data If the callout function in pcretest receives a non-zero value as callout_data, it returns that value. 50. Makefile wasn't handling CFLAGS properly when compiling dftables. Also, there were some redundant $(CFLAGS) in commands that are now specified as $(LINK), which already includes $(CFLAGS). 51. Extensions to UTF-8 support are listed below. These all apply when (a) PCRE has been compiled with UTF-8 support *and* pcre_compile() has been compiled with the PCRE_UTF8 flag. Patterns that are compiled without that flag assume one-byte characters throughout. Note that case-insensitive matching applies only to characters whose values are less than 256. PCRE doesn't support the notion of cases for higher-valued characters. (i) A character class whose characters are all within 0-255 is handled as a bit map, and the map is inverted for negative classes. Previously, a character > 255 always failed to match such a class; however it should match if the class was a negative one (e.g. [^ab]). This has been fixed. (ii) A negated character class with a single character < 255 is coded as "not this character" (OP_NOT). This wasn't working properly when the test character was multibyte, either singly or repeated. (iii) Repeats of multibyte characters are now handled correctly in UTF-8 mode, for example: \x{100}{2,3}. (iv) The character escapes \b, \B, \d, \D, \s, \S, \w, and \W (either singly or repeated) now correctly test multibyte characters. However, PCRE doesn't recognize any characters with values greater than 255 as digits, spaces, or word characters. Such characters always match \D, \S, and \W, and never match \d, \s, or \w. (v) Classes may now contain characters and character ranges with values greater than 255. For example: [ab\x{100}-\x{400}]. (vi) pcregrep now has a --utf-8 option (synonym -u) which makes it call PCRE in UTF-8 mode. 52. The info request value PCRE_INFO_FIRSTCHAR has been renamed PCRE_INFO_FIRSTBYTE because it is a byte value. However, the old name is retained for backwards compatibility. (Note that LASTLITERAL is also a byte value.) 53. The single man page has become too large. I have therefore split it up into a number of separate man pages. These also give rise to individual HTML pages; these are now put in a separate directory, and there is an index.html page that lists them all. Some hyperlinking between the pages has been installed. 54. Added convenience functions for handling named capturing parentheses. 55. Unknown escapes inside character classes (e.g. [\M]) and escapes that aren't interpreted therein (e.g. [\C]) are literals in Perl. This is now also true in PCRE, except when the PCRE_EXTENDED option is set, in which case they are faulted. 56. Introduced HOST_CC and HOST_CFLAGS which can be set in the environment when calling configure. These values are used when compiling the dftables.c program which is run to generate the source of the default character tables. They default to the values of CC and CFLAGS. If you are cross-compiling PCRE, you will need to set these values. 57. Updated the building process for Windows DLL, as provided by Fred Cox. Version 3.9 02-Jan-02 --------------------- 1. A bit of extraneous text had somehow crept into the pcregrep documentation. 2. If --disable-static was given, the building process failed when trying to build pcretest and pcregrep. (For some reason it was using libtool to compile them, which is not right, as they aren't part of the library.) Version 3.8 18-Dec-01 --------------------- 1. The experimental UTF-8 code was completely screwed up. It was packing the bytes in the wrong order. How dumb can you get? Version 3.7 29-Oct-01 --------------------- 1. In updating pcretest to check change 1 of version 3.6, I screwed up. This caused pcretest, when used on the test data, to segfault. Unfortunately, this didn't happen under Solaris 8, where I normally test things. 2. The Makefile had to be changed to make it work on BSD systems, where 'make' doesn't seem to recognize that ./xxx and xxx are the same file. (This entry isn't in ChangeLog distributed with 3.7 because I forgot when I hastily made this fix an hour or so after the initial 3.7 release.) Version 3.6 23-Oct-01 --------------------- 1. Crashed with /(sens|respons)e and \1ibility/ and "sense and sensibility" if offsets passed as NULL with zero offset count. 2. The config.guess and config.sub files had not been updated when I moved to the latest autoconf. Version 3.5 15-Aug-01 --------------------- 1. Added some missing #if !defined NOPOSIX conditionals in pcretest.c that had been forgotten. 2. By using declared but undefined structures, we can avoid using "void" definitions in pcre.h while keeping the internal definitions of the structures private. 3. The distribution is now built using autoconf 2.50 and libtool 1.4. From a user point of view, this means that both static and shared libraries are built by default, but this can be individually controlled. More of the work of handling this static/shared cases is now inside libtool instead of PCRE's make file. 4. The pcretest utility is now installed along with pcregrep because it is useful for users (to test regexs) and by doing this, it automatically gets relinked by libtool. The documentation has been turned into a man page, so there are now .1, .txt, and .html versions in /doc. 5. Upgrades to pcregrep: (i) Added long-form option names like gnu grep. (ii) Added --help to list all options with an explanatory phrase. (iii) Added -r, --recursive to recurse into sub-directories. (iv) Added -f, --file to read patterns from a file. 6. pcre_exec() was referring to its "code" argument before testing that argument for NULL (and giving an error if it was NULL). 7. Upgraded Makefile.in to allow for compiling in a different directory from the source directory. 8. Tiny buglet in pcretest: when pcre_fullinfo() was called to retrieve the options bits, the pointer it was passed was to an int instead of to an unsigned long int. This mattered only on 64-bit systems. 9. Fixed typo (3.4/1) in pcre.h again. Sigh. I had changed pcre.h (which is generated) instead of pcre.in, which it its source. Also made the same change in several of the .c files. 10. A new release of gcc defines printf() as a macro, which broke pcretest because it had an ifdef in the middle of a string argument for printf(). Fixed by using separate calls to printf(). 11. Added --enable-newline-is-cr and --enable-newline-is-lf to the configure script, to force use of CR or LF instead of \n in the source. On non-Unix systems, the value can be set in config.h. 12. The limit of 200 on non-capturing parentheses is a _nesting_ limit, not an absolute limit. Changed the text of the error message to make this clear, and likewise updated the man page. 13. The limit of 99 on the number of capturing subpatterns has been removed. The new limit is 65535, which I hope will not be a "real" limit. Version 3.4 22-Aug-00 --------------------- 1. Fixed typo in pcre.h: unsigned const char * changed to const unsigned char *. 2. Diagnose condition (?(0) as an error instead of crashing on matching. Version 3.3 01-Aug-00 --------------------- 1. If an octal character was given, but the value was greater than \377, it was not getting masked to the least significant bits, as documented. This could lead to crashes in some systems. 2. Perl 5.6 (if not earlier versions) accepts classes like [a-\d] and treats the hyphen as a literal. PCRE used to give an error; it now behaves like Perl. 3. Added the functions pcre_free_substring() and pcre_free_substring_list(). These just pass their arguments on to (pcre_free)(), but they are provided because some uses of PCRE bind it to non-C systems that can call its functions, but cannot call free() or pcre_free() directly. 4. Add "make test" as a synonym for "make check". Corrected some comments in the Makefile. 5. Add $(DESTDIR)/ in front of all the paths in the "install" target in the Makefile. 6. Changed the name of pgrep to pcregrep, because Solaris has introduced a command called pgrep for grepping around the active processes. 7. Added the beginnings of support for UTF-8 character strings. 8. Arranged for the Makefile to pass over the settings of CC, CFLAGS, and RANLIB to ./ltconfig so that they are used by libtool. I think these are all the relevant ones. (AR is not passed because ./ltconfig does its own figuring out for the ar command.) Version 3.2 12-May-00 --------------------- This is purely a bug fixing release. 1. If the pattern /((Z)+|A)*/ was matched agained ZABCDEFG it matched Z instead of ZA. This was just one example of several cases that could provoke this bug, which was introduced by change 9 of version 2.00. The code for breaking infinite loops after an iteration that matches an empty string was't working correctly. 2. The pcretest program was not imitating Perl correctly for the pattern /a*/g when matched against abbab (for example). After matching an empty string, it wasn't forcing anchoring when setting PCRE_NOTEMPTY for the next attempt; this caused it to match further down the string than it should. 3. The code contained an inclusion of sys/types.h. It isn't clear why this was there because it doesn't seem to be needed, and it causes trouble on some systems, as it is not a Standard C header. It has been removed. 4. Made 4 silly changes to the source to avoid stupid compiler warnings that were reported on the Macintosh. The changes were from while ((c = *(++ptr)) != 0 && c != '\n'); to while ((c = *(++ptr)) != 0 && c != '\n') ; Totally extraordinary, but if that's what it takes... 5. PCRE is being used in one environment where neither memmove() nor bcopy() is available. Added HAVE_BCOPY and an autoconf test for it; if neither HAVE_MEMMOVE nor HAVE_BCOPY is set, use a built-in emulation function which assumes the way PCRE uses memmove() (always moving upwards). 6. PCRE is being used in one environment where strchr() is not available. There was only one use in pcre.c, and writing it out to avoid strchr() probably gives faster code anyway. Version 3.1 09-Feb-00 --------------------- The only change in this release is the fixing of some bugs in Makefile.in for the "install" target: (1) It was failing to install pcreposix.h. (2) It was overwriting the pcre.3 man page with the pcreposix.3 man page. Version 3.0 01-Feb-00 --------------------- 1. Add support for the /+ modifier to perltest (to output $` like it does in pcretest). 2. Add support for the /g modifier to perltest. 3. Fix pcretest so that it behaves even more like Perl for /g when the pattern matches null strings. 4. Fix perltest so that it doesn't do unwanted things when fed an empty pattern. Perl treats empty patterns specially - it reuses the most recent pattern, which is not what we want. Replace // by /(?#)/ in order to avoid this effect. 5. The POSIX interface was broken in that it was just handing over the POSIX captured string vector to pcre_exec(), but (since release 2.00) PCRE has required a bigger vector, with some working space on the end. This means that the POSIX wrapper now has to get and free some memory, and copy the results. 6. Added some simple autoconf support, placing the test data and the documentation in separate directories, re-organizing some of the information files, and making it build pcre-config (a GNU standard). Also added libtool support for building PCRE as a shared library, which is now the default. 7. Got rid of the leading zero in the definition of PCRE_MINOR because 08 and 09 are not valid octal constants. Single digits will be used for minor values less than 10. 8. Defined REG_EXTENDED and REG_NOSUB as zero in the POSIX header, so that existing programs that set these in the POSIX interface can use PCRE without modification. 9. Added a new function, pcre_fullinfo() with an extensible interface. It can return all that pcre_info() returns, plus additional data. The pcre_info() function is retained for compatibility, but is considered to be obsolete. 10. Added experimental recursion feature (?R) to handle one common case that Perl 5.6 will be able to do with (?p{...}). 11. Added support for POSIX character classes like [:alpha:], which Perl is adopting. Version 2.08 31-Aug-99 ---------------------- 1. When startoffset was not zero and the pattern began with ".*", PCRE was not trying to match at the startoffset position, but instead was moving forward to the next newline as if a previous match had failed. 2. pcretest was not making use of PCRE_NOTEMPTY when repeating for /g and /G, and could get into a loop if a null string was matched other than at the start of the subject. 3. Added definitions of PCRE_MAJOR and PCRE_MINOR to pcre.h so the version can be distinguished at compile time, and for completeness also added PCRE_DATE. 5. Added Paul Sokolovsky's minor changes to make it easy to compile a Win32 DLL in GnuWin32 environments. Version 2.07 29-Jul-99 ---------------------- 1. The documentation is now supplied in plain text form and HTML as well as in the form of man page sources. 2. C++ compilers don't like assigning (void *) values to other pointer types. In particular this affects malloc(). Although there is no problem in Standard C, I've put in casts to keep C++ compilers happy. 3. Typo on pcretest.c; a cast of (unsigned char *) in the POSIX regexec() call should be (const char *). 4. If NOPOSIX is defined, pcretest.c compiles without POSIX support. This may be useful for non-Unix systems who don't want to bother with the POSIX stuff. However, I haven't made this a standard facility. The documentation doesn't mention it, and the Makefile doesn't support it. 5. The Makefile now contains an "install" target, with editable destinations at the top of the file. The pcretest program is not installed. 6. pgrep -V now gives the PCRE version number and date. 7. Fixed bug: a zero repetition after a literal string (e.g. /abcde{0}/) was causing the entire string to be ignored, instead of just the last character. 8. If a pattern like /"([^\\"]+|\\.)*"/ is applied in the normal way to a non-matching string, it can take a very, very long time, even for strings of quite modest length, because of the nested recursion. PCRE now does better in some of these cases. It does this by remembering the last required literal character in the pattern, and pre-searching the subject to ensure it is present before running the real match. In other words, it applies a heuristic to detect some types of certain failure quickly, and in the above example, if presented with a string that has no trailing " it gives "no match" very quickly. 9. A new runtime option PCRE_NOTEMPTY causes null string matches to be ignored; other alternatives are tried instead. Version 2.06 09-Jun-99 ---------------------- 1. Change pcretest's output for amount of store used to show just the code space, because the remainder (the data block) varies in size between 32-bit and 64-bit systems. 2. Added an extra argument to pcre_exec() to supply an offset in the subject to start matching at. This allows lookbehinds to work when searching for multiple occurrences in a string. 3. Added additional options to pcretest for testing multiple occurrences: /+ outputs the rest of the string that follows a match /g loops for multiple occurrences, using the new startoffset argument /G loops for multiple occurrences by passing an incremented pointer 4. PCRE wasn't doing the "first character" optimization for patterns starting with \b or \B, though it was doing it for other lookbehind assertions. That is, it wasn't noticing that a match for a pattern such as /\bxyz/ has to start with the letter 'x'. On long subject strings, this gives a significant speed-up. Version 2.05 21-Apr-99 ---------------------- 1. Changed the type of magic_number from int to long int so that it works properly on 16-bit systems. 2. Fixed a bug which caused patterns starting with .* not to work correctly when the subject string contained newline characters. PCRE was assuming anchoring for such patterns in all cases, which is not correct because .* will not pass a newline unless PCRE_DOTALL is set. It now assumes anchoring only if DOTALL is set at top level; otherwise it knows that patterns starting with .* must be retried after every newline in the subject. Version 2.04 18-Feb-99 ---------------------- 1. For parenthesized subpatterns with repeats whose minimum was zero, the computation of the store needed to hold the pattern was incorrect (too large). If such patterns were nested a few deep, this could multiply and become a real problem. 2. Added /M option to pcretest to show the memory requirement of a specific pattern. Made -m a synonym of -s (which does this globally) for compatibility. 3. Subpatterns of the form (regex){n,m} (i.e. limited maximum) were being compiled in such a way that the backtracking after subsequent failure was pessimal. Something like (a){0,3} was compiled as (a)?(a)?(a)? instead of ((a)((a)(a)?)?)? with disastrous performance if the maximum was of any size. Version 2.03 02-Feb-99 ---------------------- 1. Fixed typo and small mistake in man page. 2. Added 4th condition (GPL supersedes if conflict) and created separate LICENCE file containing the conditions. 3. Updated pcretest so that patterns such as /abc\/def/ work like they do in Perl, that is the internal \ allows the delimiter to be included in the pattern. Locked out the use of \ as a delimiter. If \ immediately follows the final delimiter, add \ to the end of the pattern (to test the error). 4. Added the convenience functions for extracting substrings after a successful match. Updated pcretest to make it able to test these functions. Version 2.02 14-Jan-99 ---------------------- 1. Initialized the working variables associated with each extraction so that their saving and restoring doesn't refer to uninitialized store. 2. Put dummy code into study.c in order to trick the optimizer of the IBM C compiler for OS/2 into generating correct code. Apparently IBM isn't going to fix the problem. 3. Pcretest: the timing code wasn't using LOOPREPEAT for timing execution calls, and wasn't printing the correct value for compiling calls. Increased the default value of LOOPREPEAT, and the number of significant figures in the times. 4. Changed "/bin/rm" in the Makefile to "-rm" so it works on Windows NT. 5. Renamed "deftables" as "dftables" to get it down to 8 characters, to avoid a building problem on Windows NT with a FAT file system. Version 2.01 21-Oct-98 ---------------------- 1. Changed the API for pcre_compile() to allow for the provision of a pointer to character tables built by pcre_maketables() in the current locale. If NULL is passed, the default tables are used. Version 2.00 24-Sep-98 ---------------------- 1. Since the (>?) facility is in Perl 5.005, don't require PCRE_EXTRA to enable it any more. 2. Allow quantification of (?>) groups, and make it work correctly. 3. The first character computation wasn't working for (?>) groups. 4. Correct the implementation of \Z (it is permitted to match on the \n at the end of the subject) and add 5.005's \z, which really does match only at the very end of the subject. 5. Remove the \X "cut" facility; Perl doesn't have it, and (?> is neater. 6. Remove the ability to specify CASELESS, MULTILINE, DOTALL, and DOLLAR_END_ONLY at runtime, to make it possible to implement the Perl 5.005 localized options. All options to pcre_study() were also removed. 7. Add other new features from 5.005: $(?<= positive lookbehind $(?a*))*/ (a PCRE_EXTRA facility). Version 1.00 18-Nov-97 ---------------------- 1. Added compile-time macros to support systems such as SunOS4 which don't have memmove() or strerror() but have other things that can be used instead. 2. Arranged that "make clean" removes the executables. Version 0.99 27-Oct-97 ---------------------- 1. Fixed bug in code for optimizing classes with only one character. It was initializing a 32-byte map regardless, which could cause it to run off the end of the memory it had got. 2. Added, conditional on PCRE_EXTRA, the proposed (?>REGEX) construction. Version 0.98 22-Oct-97 ---------------------- 1. Fixed bug in code for handling temporary memory usage when there are more back references than supplied space in the ovector. This could cause segfaults. Version 0.97 21-Oct-97 ---------------------- 1. Added the \X "cut" facility, conditional on PCRE_EXTRA. 2. Optimized negated single characters not to use a bit map. 3. Brought error texts together as macro definitions; clarified some of them; fixed one that was wrong - it said "range out of order" when it meant "invalid escape sequence". 4. Changed some char * arguments to const char *. 5. Added PCRE_NOTBOL and PCRE_NOTEOL (from POSIX). 6. Added the POSIX-style API wrapper in pcreposix.a and testing facilities in pcretest. Version 0.96 16-Oct-97 ---------------------- 1. Added a simple "pgrep" utility to the distribution. 2. Fixed an incompatibility with Perl: "{" is now treated as a normal character unless it appears in one of the precise forms "{ddd}", "{ddd,}", or "{ddd,ddd}" where "ddd" means "one or more decimal digits". 3. Fixed serious bug. If a pattern had a back reference, but the call to pcre_exec() didn't supply a large enough ovector to record the related identifying subpattern, the match always failed. PCRE now remembers the number of the largest back reference, and gets some temporary memory in which to save the offsets during matching if necessary, in order to ensure that backreferences always work. 4. Increased the compatibility with Perl in a number of ways: (a) . no longer matches \n by default; an option PCRE_DOTALL is provided to request this handling. The option can be set at compile or exec time. (b) $ matches before a terminating newline by default; an option PCRE_DOLLAR_ENDONLY is provided to override this (but not in multiline mode). The option can be set at compile or exec time. (c) The handling of \ followed by a digit other than 0 is now supposed to be the same as Perl's. If the decimal number it represents is less than 10 or there aren't that many previous left capturing parentheses, an octal escape is read. Inside a character class, it's always an octal escape, even if it is a single digit. (d) An escaped but undefined alphabetic character is taken as a literal, unless PCRE_EXTRA is set. Currently this just reserves the remaining escapes. (e) {0} is now permitted. (The previous item is removed from the compiled pattern). 5. Changed all the names of code files so that the basic parts are no longer than 10 characters, and abolished the teeny "globals.c" file. 6. Changed the handling of character classes; they are now done with a 32-byte bit map always. 7. Added the -d and /D options to pcretest to make it possible to look at the internals of compilation without having to recompile pcre. Version 0.95 23-Sep-97 ---------------------- 1. Fixed bug in pre-pass concerning escaped "normal" characters such as \x5c or \x20 at the start of a run of normal characters. These were being treated as real characters, instead of the source characters being re-checked. Version 0.94 18-Sep-97 ---------------------- 1. The functions are now thread-safe, with the caveat that the global variables containing pointers to malloc() and free() or alternative functions are the same for all threads. 2. Get pcre_study() to generate a bitmap of initial characters for non- anchored patterns when this is possible, and use it if passed to pcre_exec(). Version 0.93 15-Sep-97 ---------------------- 1. /(b)|(:+)/ was computing an incorrect first character. 2. Add pcre_study() to the API and the passing of pcre_extra to pcre_exec(), but not actually doing anything yet. 3. Treat "-" characters in classes that cannot be part of ranges as literals, as Perl does (e.g. [-az] or [az-]). 4. Set the anchored flag if a branch starts with .* or .*? because that tests all possible positions. 5. Split up into different modules to avoid including unneeded functions in a compiled binary. However, compile and exec are still in one module. The "study" function is split off. 6. The character tables are now in a separate module whose source is generated by an auxiliary program - but can then be edited by hand if required. There are now no calls to isalnum(), isspace(), isdigit(), isxdigit(), tolower() or toupper() in the code. 7. Turn the malloc/free funtions variables into pcre_malloc and pcre_free and make them global. Abolish the function for setting them, as the caller can now set them directly. Version 0.92 11-Sep-97 ---------------------- 1. A repeat with a fixed maximum and a minimum of 1 for an ordinary character (e.g. /a{1,3}/) was broken (I mis-optimized it). 2. Caseless matching was not working in character classes if the characters in the pattern were in upper case. 3. Make ranges like [W-c] work in the same way as Perl for caseless matching. 4. Make PCRE_ANCHORED public and accept as a compile option. 5. Add an options word to pcre_exec() and accept PCRE_ANCHORED and PCRE_CASELESS at run time. Add escapes \A and \I to pcretest to cause it to pass them. 6. Give an error if bad option bits passed at compile or run time. 7. Add PCRE_MULTILINE at compile and exec time, and (?m) as well. Add \M to pcretest to cause it to pass that flag. 8. Add pcre_info(), to get the number of identifying subpatterns, the stored options, and the first character, if set. 9. Recognize C+ or C{n,m} where n >= 1 as providing a fixed starting character. Version 0.91 10-Sep-97 ---------------------- 1. PCRE was failing to diagnose unlimited repeats of subpatterns that could match the empty string as in /(a*)*/. It was looping and ultimately crashing. 2. PCRE was looping on encountering an indefinitely repeated back reference to a subpattern that had matched an empty string, e.g. /(a|)\1*/. It now does what Perl does - treats the match as successful. **** usr/doc/pcre-4.4/INSTALL0100644000000000000000000001756107721121073013432 0ustar rootrootBasic Installation ================== These are generic installation instructions that apply to systems that can run the `configure' shell script - Unix systems and any that imitate it. They are not specific to PCRE. There are PCRE-specific instructions for non-Unix systems in the file NON-UNIX-USE. The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, a file `config.cache' that saves the results of its tests to speed up reconfiguring, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If at some point `config.cache' contains results you don't want to keep, you may remove or edit it. The file `configure.in' is used to create `configure' by a program called `autoconf'. You only need `configure.in' if you want to change it or regenerate `configure' using a newer version of `autoconf'. The simplest way to compile this package is: 1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself. Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for. 2. Type `make' to compile the package. 3. Optionally, type `make check' to run any self-tests that come with the package. 4. Type `make install' to install the programs and any data files and documentation. 5. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Compilers and Options ===================== Some systems require unusual options for compilation or linking that the `configure' script does not know about. You can give `configure' initial values for variables by setting them in the environment. Using a Bourne-compatible shell, you can do that on the command line like this: CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure Or on systems that have the `env' program, you can do it like this: env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure Compiling For Multiple Architectures ==================================== You can compile the package for more than one kind of computer at the same time, by placing the object files for each architecture in their own directory. To do this, you must use a version of `make' that supports the `VPATH' variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'. If you have to use a `make' that does not supports the `VPATH' variable, you have to compile the package for one architecture at a time in the source code directory. After you have installed the package for one architecture, use `make distclean' before reconfiguring for another architecture. Installation Names ================== By default, `make install' will install the package's files in `/usr/local/bin', `/usr/local/man', etc. You can specify an installation prefix other than `/usr/local' by giving `configure' the option `--prefix=PATH'. You can specify separate installation prefixes for architecture-specific files and architecture-independent files. If you give `configure' the option `--exec-prefix=PATH', the package will use PATH as the prefix for installing programs and libraries. Documentation and other data files will still use the regular prefix. In addition, if you use an unusual directory layout you can give options like `--bindir=PATH' to specify different values for particular kinds of files. Run `configure --help' for a list of the directories you can set and what kinds of files go in them. If the package supports it, you can cause programs to be installed with an extra prefix or suffix on their names by giving `configure' the option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'. Optional Features ================= Some packages pay attention to `--enable-FEATURE' options to `configure', where FEATURE indicates an optional part of the package. They may also pay attention to `--with-PACKAGE' options, where PACKAGE is something like `gnu-as' or `x' (for the X Window System). The `README' should mention any `--enable-' and `--with-' options that the package recognizes. For packages that use the X Window System, `configure' can usually find the X include and library files automatically, but if it doesn't, you can use the `configure' options `--x-includes=DIR' and `--x-libraries=DIR' to specify their locations. Specifying the System Type ========================== There may be some features `configure' can not figure out automatically, but needs to determine by the type of host the package will run on. Usually `configure' can figure that out, but if it prints a message saying it can not guess the host type, give it the `--host=TYPE' option. TYPE can either be a short name for the system type, such as `sun4', or a canonical name with three fields: CPU-COMPANY-SYSTEM See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the host type. If you are building compiler tools for cross-compiling, you can also use the `--target=TYPE' option to select the type of system they will produce code for and the `--build=TYPE' option to select the type of system on which you are compiling the package. Sharing Defaults ================ If you want to set default values for `configure' scripts to share, you can create a site shell script called `config.site' that gives default values for variables like `CC', `cache_file', and `prefix'. `configure' looks for `PREFIX/share/config.site' if it exists, then `PREFIX/etc/config.site' if it exists. Or, you can set the `CONFIG_SITE' environment variable to the location of the site script. A warning: not all `configure' scripts look for a site script. Operation Controls ================== `configure' recognizes the following options to control how it operates. `--cache-file=FILE' Use and save the results of the tests in FILE instead of `./config.cache'. Set FILE to `/dev/null' to disable caching, for debugging `configure'. `--help' Print a summary of the options to `configure', and exit. `--quiet' `--silent' `-q' Do not print messages saying which checks are being made. To suppress all normal output, redirect it to `/dev/null' (any error messages will still be shown). `--srcdir=DIR' Look for the package's source code in directory DIR. Usually `configure' can determine that directory automatically. `--version' Print the version of Autoconf used to generate the `configure' script, and exit. `configure' also accepts some other, not widely useful, options. usr/doc/pcre-4.4/LICENCE0100644000000000000000000000425207721121073013357 0ustar rootrootPCRE LICENCE ------------ PCRE is a library of functions to support regular expressions whose syntax and semantics are as close as possible to those of the Perl 5 language. Written by: Philip Hazel University of Cambridge Computing Service, Cambridge, England. Phone: +44 1223 334714. Copyright (c) 1997-2003 University of Cambridge Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions: 1. This software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 2. The origin of this software must not be misrepresented, either by explicit claim or by omission. In practice, this means that if you use PCRE in software that you distribute to others, commercially or otherwise, you must put a sentence like this Regular expression support is provided by the PCRE library package, which is open source software, written by Philip Hazel, and copyright by the University of Cambridge, England. somewhere reasonably visible in your documentation and in any relevant files or online help data or similar. A reference to the ftp site for the source, that is, to ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ should also be given in the documentation. However, this condition is not intended to apply to whole chains of software. If package A includes PCRE, it must acknowledge it, but if package B is software that includes package A, the condition is not imposed on package B (unless it uses PCRE independently). 3. Altered versions must be plainly marked as such, and must not be misrepresented as being the original software. 4. If PCRE is embedded in any software that is released under the GNU General Purpose Licence (GPL), or Lesser General Purpose Licence (LGPL), then the terms of that licence shall supersede any condition above with which it is incompatible. The documentation for PCRE, supplied in the "doc" directory, is distributed under the same terms as the software itself. End usr/doc/pcre-4.4/NEWS0100644000000000000000000001261207721121073013070 0ustar rootrootNews about PCRE releases ------------------------ Release 4.4 21-Aug-03 --------------------- This is mainly a bug-fix and tidying release. The only new feature is that PCRE checks UTF-8 strings for validity by default. There is an option to suppress this, just in case anybody wants that teeny extra bit of performance. Releases 4.1 - 4.3 ------------------ Sorry, I forgot about updating the NEWS file for these releases. Please take a look at ChangeLog. Release 4.0 17-Feb-03 --------------------- There have been a lot of changes for the 4.0 release, adding additional functionality and mending bugs. Below is a list of the highlights of the new functionality. For full details of these features, please consult the documentation. For a complete list of changes, see the ChangeLog file. 1. Support for Perl's \Q...\E escapes. 2. "Possessive quantifiers" ?+, *+, ++, and {,}+ which come from Sun's Java package. They provide some syntactic sugar for simple cases of "atomic grouping". 3. Support for the \G assertion. It is true when the current matching position is at the start point of the match. 4. A new feature that provides some of the functionality that Perl provides with (?{...}). The facility is termed a "callout". The way it is done in PCRE is for the caller to provide an optional function, by setting pcre_callout to its entry point. To get the function called, the regex must include (?C) at appropriate points. 5. Support for recursive calls to individual subpatterns. This makes it really easy to get totally confused. 6. Support for named subpatterns. The Python syntax (?P...) is used to name a group. 7. Several extensions to UTF-8 support; it is now fairly complete. There is an option for pcregrep to make it operate in UTF-8 mode. 8. The single man page has been split into a number of separate man pages. These also give rise to individual HTML pages which are put in a separate directory. There is an index.html page that lists them all. Some hyperlinking between the pages has been installed. Release 3.5 15-Aug-01 --------------------- 1. The configuring system has been upgraded to use later versions of autoconf and libtool. By default it builds both a shared and a static library if the OS supports it. You can use --disable-shared or --disable-static on the configure command if you want only one of them. 2. The pcretest utility is now installed along with pcregrep because it is useful for users (to test regexs) and by doing this, it automatically gets relinked by libtool. The documentation has been turned into a man page, so there are now .1, .txt, and .html versions in /doc. 3. Upgrades to pcregrep: (i) Added long-form option names like gnu grep. (ii) Added --help to list all options with an explanatory phrase. (iii) Added -r, --recursive to recurse into sub-directories. (iv) Added -f, --file to read patterns from a file. 4. Added --enable-newline-is-cr and --enable-newline-is-lf to the configure script, to force use of CR or LF instead of \n in the source. On non-Unix systems, the value can be set in config.h. 5. The limit of 200 on non-capturing parentheses is a _nesting_ limit, not an absolute limit. Changed the text of the error message to make this clear, and likewise updated the man page. 6. The limit of 99 on the number of capturing subpatterns has been removed. The new limit is 65535, which I hope will not be a "real" limit. Release 3.3 01-Aug-00 --------------------- There is some support for UTF-8 character strings. This is incomplete and experimental. The documentation describes what is and what is not implemented. Otherwise, this is just a bug-fixing release. Release 3.0 01-Feb-00 --------------------- 1. A "configure" script is now used to configure PCRE for Unix systems. It builds a Makefile, a config.h file, and the pcre-config script. 2. PCRE is built as a shared library by default. 3. There is support for POSIX classes such as [:alpha:]. 5. There is an experimental recursion feature. ---------------------------------------------------------------------------- IMPORTANT FOR THOSE UPGRADING FROM VERSIONS BEFORE 2.00 Please note that there has been a change in the API such that a larger ovector is required at matching time, to provide some additional workspace. The new man page has details. This change was necessary in order to support some of the new functionality in Perl 5.005. IMPORTANT FOR THOSE UPGRADING FROM VERSION 2.00 Another (I hope this is the last!) change has been made to the API for the pcre_compile() function. An additional argument has been added to make it possible to pass over a pointer to character tables built in the current locale by pcre_maketables(). To use the default tables, this new arguement should be passed as NULL. IMPORTANT FOR THOSE UPGRADING FROM VERSION 2.05 Yet another (and again I hope this really is the last) change has been made to the API for the pcre_exec() function. An additional argument has been added to make it possible to start the match other than at the start of the subject string. This is important if there are lookbehinds. The new man page has the details, but you just want to convert existing programs, all you need to do is to stick in a new fifth argument to pcre_exec(), with a value of zero. For example, change pcre_exec(pattern, extra, subject, length, options, ovec, ovecsize) to pcre_exec(pattern, extra, subject, length, 0, options, ovec, ovecsize) **** usr/doc/pcre-4.4/NON-UNIX-USE0100644000000000000000000001126607721121073014165 0ustar rootrootCompiling PCRE on non-Unix systems ---------------------------------- See below for comments on Cygwin or MinGW usage. If you want to compile PCRE for a non-Unix system, note that it consists entirely of code written in Standard C, and so should compile successfully on any machine with a Standard C compiler and library, using normal compiling commands to do the following: (1) Copy or rename the file config.in as config.h, and change the macros that define HAVE_STRERROR and HAVE_MEMMOVE to define them as 1 rather than 0. Unfortunately, because of the way Unix autoconf works, the default setting has to be 0. You may also want to make changes to other macros in config.h. In particular, if you want to force a specific value for newline, you can define the NEWLINE macro. The default is to use '\n', thereby using whatever value your compiler gives to '\n'. (2) Copy or rename the file pcre.in as pcre.h, and change the macro definitions for PCRE_MAJOR, PCRE_MINOR, and PCRE_DATE near its start to the values set in configure.in. (3) Compile dftables.c as a stand-alone program, and then run it with the standard output sent to chartables.c. This generates a set of standard character tables. (4) Compile maketables.c, get.c, study.c and pcre.c and link them all together into an object library in whichever form your system keeps such libraries. This is the pcre library (chartables.c is included by means of an #include directive). (5) Similarly, compile pcreposix.c and link it as the pcreposix library. (6) Compile the test program pcretest.c. This needs the functions in the pcre and pcreposix libraries when linking. (7) Run pcretest on the testinput files in the testdata directory, and check that the output matches the corresponding testoutput files. You must use the -i option when checking testinput2. Note that the supplied files are in Unix format, with just LF characters as line terminators. You may need to edit them to change this if your system uses a different convention. If you have a system without "configure" but where you can use a Makefile, edit Makefile.in to create Makefile, substituting suitable values for the variables at the head of the file. Some help in building a Win32 DLL of PCRE in GnuWin32 environments was contributed by Paul Sokolovsky. These environments are Mingw32 (http://www.xraylith.wisc.edu/~khan/software/gnu-win32/) and CygWin (http://sourceware.cygnus.com/cygwin/). Paul comments: For CygWin, set CFLAGS=-mno-cygwin, and do 'make dll'. You'll get pcre.dll (containing pcreposix also), libpcre.dll.a, and dynamically linked pgrep and pcretest. If you have /bin/sh, run RunTest (three main test go ok, locale not supported). Changes to do MinGW with autoconf 2.50 were supplied by Fred Cox , who comments as follows: If you are using the PCRE DLL, the normal Unix style configure && make && make check && make install should just work[*]. If you want to statically link against the .a file, you must define PCRE_STATIC before including pcre.h, otherwise the pcre_malloc and pcre_free exported functions will be declared __declspec(dllimport), with hilarious results. See the configure.in and pcretest.c for how it is done for the static test. Also, there will only be a libpcre.la, not a libpcreposix.la, as you would expect from the Unix version. The single DLL includes the pcreposix interface. [*] But note that the supplied test files are in Unix format, with just LF characters as line terminators. You will have to edit them to change to CR LF terminators. A script for building PCRE using Borland's C++ compiler for use with VPASCAL was contributed by Alexander Tokarev. It is called makevp.bat. These are some further comments about Win32 builds from Mark Evans. They were contributed before Fred Cox's changes were made, so it is possible that they may no longer be relevant. The documentation for Win32 builds is a bit shy. Under MSVC6 I followed their instructions to the letter, but there were still some things missing. (1) Must #define STATIC for entire project if linking statically. (I see no reason to use DLLs for code this compact.) This of course is a project setting in MSVC under Preprocessor. (2) Missing some #ifdefs relating to the function pointers pcre_malloc and pcre_free. See my solution below. (The stubs may not be mandatory but they made me feel better.) ========================= #ifdef _WIN32 #include void* malloc_stub(size_t N) { return malloc(N); } void free_stub(void* p) { free(p); } void *(*pcre_malloc)(size_t) = &malloc_stub; void (*pcre_free)(void *) = &free_stub; #else void *(*pcre_malloc)(size_t) = malloc; void (*pcre_free)(void *) = free; #endif ========================= **** usr/doc/pcre-4.4/README0100644000000000000000000003771707721121073013266 0ustar rootrootREADME file for PCRE (Perl-compatible regular expression library) ----------------------------------------------------------------- The latest release of PCRE is always available from ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-xxx.tar.gz Please read the NEWS file if you are upgrading from a previous release. PCRE has its own native API, but a set of "wrapper" functions that are based on the POSIX API are also supplied in the library libpcreposix. Note that this just provides a POSIX calling interface to PCRE: the regular expressions themselves still follow Perl syntax and semantics. The header file for the POSIX-style functions is called pcreposix.h. The official POSIX name is regex.h, but I didn't want to risk possible problems with existing files of that name by distributing it that way. To use it with an existing program that uses the POSIX API, it will have to be renamed or pointed at by a link. Contributions by users of PCRE ------------------------------ You can find contributions from PCRE users in the directory ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/Contrib where there is also a README file giving brief descriptions of what they are. Several of them provide support for compiling PCRE on various flavours of Windows systems (I myself do not use Windows). Some are complete in themselves; others are pointers to URLs containing relevant files. Building PCRE on a Unix-like system ----------------------------------- To build PCRE on a Unix-like system, first run the "configure" command from the PCRE distribution directory, with your current directory set to the directory where you want the files to be created. This command is a standard GNU "autoconf" configuration script, for which generic instructions are supplied in INSTALL. Most commonly, people build PCRE within its own distribution directory, and in this case, on many systems, just running "./configure" is sufficient, but the usual methods of changing standard defaults are available. For example, CFLAGS='-O2 -Wall' ./configure --prefix=/opt/local specifies that the C compiler should be run with the flags '-O2 -Wall' instead of the default, and that "make install" should install PCRE under /opt/local instead of the default /usr/local. If you want to build in a different directory, just run "configure" with that directory as current. For example, suppose you have unpacked the PCRE source into /source/pcre/pcre-xxx, but you want to build it in /build/pcre/pcre-xxx: cd /build/pcre/pcre-xxx /source/pcre/pcre-xxx/configure There are some optional features that can be included or omitted from the PCRE library. You can read more about them in the pcrebuild man page. . If you want to make use of the support for UTF-8 character strings in PCRE, you must add --enable-utf8 to the "configure" command. Without it, the code for handling UTF-8 is not included in the library. (Even when included, it still has to be enabled by an option at run time.) . You can build PCRE to recognized CR or NL as the newline character, instead of whatever your compiler uses for "\n", by adding --newline-is-cr or --newline-is-nl to the "configure" command, respectively. Only do this if you really understand what you are doing. On traditional Unix-like systems, the newline character is NL. . When called via the POSIX interface, PCRE uses malloc() to get additional storage for processing capturing parentheses if there are more than 10 of them. You can increase this threshold by setting, for example, --with-posix-malloc-threshold=20 on the "configure" command. . PCRE has a counter which can be set to limit the amount of resources it uses. If the limit is exceeded during a match, the match fails. The default is ten million. You can change the default by setting, for example, --with-match-limit=500000 on the "configure" command. This is just the default; individual calls to pcre_exec() can supply their own value. There is discussion on the pcreapi man page. . The default maximum compiled pattern size is around 64K. You can increase this by adding --with-link-size=3 to the "configure" command. You can increase it even more by setting --with-link-size=4, but this is unlikely ever to be necessary. If you build PCRE with an increased link size, test 2 (and 5 if you are using UTF-8) will fail. Part of the output of these tests is a representation of the compiled pattern, and this changes with the link size. The "configure" script builds five files: . libtool is a script that builds shared and/or static libraries . Makefile is built by copying Makefile.in and making substitutions. . config.h is built by copying config.in and making substitutions. . pcre-config is built by copying pcre-config.in and making substitutions. . RunTest is a script for running tests Once "configure" has run, you can run "make". It builds two libraries called libpcre and libpcreposix, a test program called pcretest, and the pcregrep command. You can use "make install" to copy these, the public header files pcre.h and pcreposix.h, and the man pages to appropriate live directories on your system, in the normal way. Running "make install" also installs the command pcre-config, which can be used to recall information about the PCRE configuration and installation. For example, pcre-config --version prints the version number, and pcre-config --libs outputs information about where the library is installed. This command can be included in makefiles for programs that use PCRE, saving the programmer from having to remember too many details. Cross-compiling PCRE on a Unix-like system ------------------------------------------ PCRE needs to compile and run an auxiliary program as part of the building process. Obviously, if the real compilation is for some other system, it can't use the same CC and CFLAGS values when it is doing this. For cross compilation, therefore, you must set CC_FOR_BUILD to the local host's compiler, and you can set flags in CFLAGS_FOR_BUILD if you need to. Shared libraries on Unix-like systems ------------------------------------- The default distribution builds PCRE as two shared libraries and two static libraries, as long as the operating system supports shared libraries. Shared library support relies on the "libtool" script which is built as part of the "configure" process. The libtool script is used to compile and link both shared and static libraries. They are placed in a subdirectory called .libs when they are newly built. The programs pcretest and pcregrep are built to use these uninstalled libraries (by means of wrapper scripts in the case of shared libraries). When you use "make install" to install shared libraries, pcregrep and pcretest are automatically re-built to use the newly installed shared libraries before being installed themselves. However, the versions left in the source directory still use the uninstalled libraries. To build PCRE using static libraries only you must use --disable-shared when configuring it. For example ./configure --prefix=/usr/gnu --disable-shared Then run "make" in the usual way. Similarly, you can use --disable-static to build only shared libraries. Cross-compiling on a Unix-like system ------------------------------------- You can specify CC and CFLAGS in the normal way to the "configure" command, in order to cross-compile PCRE for some other host. However, during the building process, the dftables.c source file is compiled *and run* on the local host, in order to generate the default character tables (the chartables.c file). It therefore needs to be compiled with the local compiler, not the cross compiler. You can do this by specifying HOST_CC (and if necessary HOST_CFLAGS) when calling the "configure" command. If they are not specified, they default to the values of CC and CFLAGS. Building on non-Unix systems ---------------------------- For a non-Unix system, read the comments in the file NON-UNIX-USE. PCRE has been compiled on Windows systems and on Macintoshes, but I don't know the details because I don't use those systems. It should be straightforward to build PCRE on any system that has a Standard C compiler, because it uses only Standard C functions. Testing PCRE ------------ To test PCRE on a Unix system, run the RunTest script that is created by the configuring process. (This can also be run by "make runtest", "make check", or "make test".) For other systems, see the instruction in NON-UNIX-USE. The script runs the pcretest test program (which is documented in its own man page) on each of the testinput files (in the testdata directory) in turn, and compares the output with the contents of the corresponding testoutput file. A file called testtry is used to hold the output from pcretest. To run pcretest on just one of the test files, give its number as an argument to RunTest, for example: RunTest 2 The first file can also be fed directly into the perltest script to check that Perl gives the same results. The only difference you should see is in the first few lines, where the Perl version is given instead of the PCRE version. The second set of tests check pcre_fullinfo(), pcre_info(), pcre_study(), pcre_copy_substring(), pcre_get_substring(), pcre_get_substring_list(), error detection, and run-time flags that are specific to PCRE, as well as the POSIX wrapper API. It also uses the debugging flag to check some of the internals of pcre_compile(). If you build PCRE with a locale setting that is not the standard C locale, the character tables may be different (see next paragraph). In some cases, this may cause failures in the second set of tests. For example, in a locale where the isprint() function yields TRUE for characters in the range 128-255, the use of [:isascii:] inside a character class defines a different set of characters, and this shows up in this test as a difference in the compiled code, which is being listed for checking. Where the comparison test output contains [\x00-\x7f] the test will contain [\x00-\xff], and similarly in some other cases. This is not a bug in PCRE. The third set of tests checks pcre_maketables(), the facility for building a set of character tables for a specific locale and using them instead of the default tables. The tests make use of the "fr" (French) locale. Before running the test, the script checks for the presence of this locale by running the "locale" command. If that command fails, or if it doesn't include "fr" in the list of available locales, the third test cannot be run, and a comment is output to say why. If running this test produces instances of the error ** Failed to set locale "fr" in the comparison output, it means that locale is not available on your system, despite being listed by "locale". This does not mean that PCRE is broken. The fourth test checks the UTF-8 support. It is not run automatically unless PCRE is built with UTF-8 support. To do this you must set --enable-utf8 when running "configure". This file can be also fed directly to the perltest script, provided you are running Perl 5.8 or higher. (For Perl 5.6, a small patch, commented in the script, can be be used.) The fifth and final file tests error handling with UTF-8 encoding, and internal UTF-8 features of PCRE that are not relevant to Perl. Character tables ---------------- PCRE uses four tables for manipulating and identifying characters. The final argument of the pcre_compile() function is a pointer to a block of memory containing the concatenated tables. A call to pcre_maketables() can be used to generate a set of tables in the current locale. If the final argument for pcre_compile() is passed as NULL, a set of default tables that is built into the binary is used. The source file called chartables.c contains the default set of tables. This is not supplied in the distribution, but is built by the program dftables (compiled from dftables.c), which uses the ANSI C character handling functions such as isalnum(), isalpha(), isupper(), islower(), etc. to build the table sources. This means that the default C locale which is set for your system will control the contents of these default tables. You can change the default tables by editing chartables.c and then re-building PCRE. If you do this, you should probably also edit Makefile to ensure that the file doesn't ever get re-generated. The first two 256-byte tables provide lower casing and case flipping functions, respectively. The next table consists of three 32-byte bit maps which identify digits, "word" characters, and white space, respectively. These are used when building 32-byte bit maps that represent character classes. The final 256-byte table has bits indicating various character types, as follows: 1 white space character 2 letter 4 decimal digit 8 hexadecimal digit 16 alphanumeric or '_' 128 regular expression metacharacter or binary zero You should not alter the set of characters that contain the 128 bit, as that will cause PCRE to malfunction. Manifest -------- The distribution should contain the following files: (A) The actual source files of the PCRE library functions and their headers: dftables.c auxiliary program for building chartables.c get.c ) maketables.c ) study.c ) source of pcre.c ) the functions pcreposix.c ) printint.c ) pcre.in "source" for the header for the external API; pcre.h is built from this by "configure" pcreposix.h header for the external POSIX wrapper API internal.h header for internal use config.in template for config.h, which is built by configure (B) Auxiliary files: AUTHORS information about the author of PCRE ChangeLog log of changes to the code INSTALL generic installation instructions LICENCE conditions for the use of PCRE COPYING the same, using GNU's standard name Makefile.in template for Unix Makefile, which is built by configure NEWS important changes in this release NON-UNIX-USE notes on building PCRE on non-Unix systems README this file RunTest.in template for a Unix shell script for running tests config.guess ) files used by libtool, config.sub ) used only when building a shared library configure a configuring shell script (built by autoconf) configure.in the autoconf input used to build configure doc/Tech.Notes notes on the encoding doc/*.3 man page sources for the PCRE functions doc/*.1 man page sources for pcregrep and pcretest doc/html/* HTML documentation doc/pcre.txt plain text version of the man pages doc/pcretest.txt plain text documentation of test program doc/perltest.txt plain text documentation of Perl test program install-sh a shell script for installing files ltmain.sh file used to build a libtool script pcretest.c comprehensive test program pcredemo.c simple demonstration of coding calls to PCRE perltest Perl test program pcregrep.c source of a grep utility that uses PCRE pcre-config.in source of script which retains PCRE information testdata/testinput1 test data, compatible with Perl testdata/testinput2 test data for error messages and non-Perl things testdata/testinput3 test data for locale-specific tests testdata/testinput4 test data for UTF-8 tests compatible with Perl testdata/testinput5 test data for other UTF-8 tests testdata/testoutput1 test results corresponding to testinput1 testdata/testoutput2 test results corresponding to testinput2 testdata/testoutput3 test results corresponding to testinput3 testdata/testoutput4 test results corresponding to testinput4 testdata/testoutput5 test results corresponding to testinput5 (C) Auxiliary files for Win32 DLL dll.mk pcre.def (D) Auxiliary file for VPASCAL makevp.bat Philip Hazel February 2003 usr/doc/pcre-4.4/Tech.Notes0100644000000000000000000002626207721121074014275 0ustar rootrootTechnical Notes about PCRE -------------------------- Many years ago I implemented some regular expression functions to an algorithm suggested by Martin Richards. These were not Unix-like in form, and were quite restricted in what they could do by comparison with Perl. The interesting part about the algorithm was that the amount of space required to hold the compiled form of an expression was known in advance. The code to apply an expression did not operate by backtracking, as the original Henry Spencer code and current Perl code does, but instead checked all possibilities simultaneously by keeping a list of current states and checking all of them as it advanced through the subject string. (In the terminology of Jeffrey Friedl's book, it was a "DFA algorithm".) When the pattern was all used up, all remaining states were possible matches, and the one matching the longest subset of the subject string was chosen. This did not necessarily maximize the individual wild portions of the pattern, as is expected in Unix and Perl-style regular expressions. By contrast, the code originally written by Henry Spencer and subsequently heavily modified for Perl actually compiles the expression twice: once in a dummy mode in order to find out how much store will be needed, and then for real. The execution function operates by backtracking and maximizing (or, optionally, minimizing in Perl) the amount of the subject that matches individual wild portions of the pattern. This is an "NFA algorithm" in Friedl's terminology. For the set of functions that forms PCRE (which are unrelated to those mentioned above), I tried at first to invent an algorithm that used an amount of store bounded by a multiple of the number of characters in the pattern, to save on compiling time. However, because of the greater complexity in Perl regular expressions, I couldn't do this. In any case, a first pass through the pattern is needed, for a number of reasons. PCRE works by running a very degenerate first pass to calculate a maximum store size, and then a second pass to do the real compile - which may use a bit less than the predicted amount of store. The idea is that this is going to turn out faster because the first pass is degenerate and the second pass can just store stuff straight into the vector. It does make the compiling functions bigger, of course, but they have got quite big anyway to handle all the Perl stuff. The compiled form of a pattern is a vector of bytes, containing items of variable length. The first byte in an item is an opcode, and the length of the item is either implicit in the opcode or contained in the data bytes which follow it. A list of all the opcodes follows: Opcodes with no following data ------------------------------ These items are all just one byte long OP_END end of pattern OP_ANY match any character OP_ANYBYTE match any single byte, even in UTF-8 mode OP_SOD match start of data: \A OP_SOM, start of match (subject + offset): \G OP_CIRC ^ (start of data, or after \n in multiline) OP_NOT_WORD_BOUNDARY \W OP_WORD_BOUNDARY \w OP_NOT_DIGIT \D OP_DIGIT \d OP_NOT_WHITESPACE \S OP_WHITESPACE \s OP_NOT_WORDCHAR \W OP_WORDCHAR \w OP_EODN match end of data or \n at end: \Z OP_EOD match end of data: \z OP_DOLL $ (end of data, or before \n in multiline) Repeating single characters --------------------------- The common repeats (*, +, ?) when applied to a single character appear as two-byte items using the following opcodes: OP_STAR OP_MINSTAR OP_PLUS OP_MINPLUS OP_QUERY OP_MINQUERY Those with "MIN" in their name are the minimizing versions. Each is followed by the character that is to be repeated. Other repeats make use of OP_UPTO OP_MINUPTO OP_EXACT which are followed by a two-byte count (most significant first) and the repeated character. OP_UPTO matches from 0 to the given number. A repeat with a non-zero minimum and a fixed maximum is coded as an OP_EXACT followed by an OP_UPTO (or OP_MINUPTO). Repeating character types ------------------------- Repeats of things like \d are done exactly as for single characters, except that instead of a character, the opcode for the type is stored in the data byte. The opcodes are: OP_TYPESTAR OP_TYPEMINSTAR OP_TYPEPLUS OP_TYPEMINPLUS OP_TYPEQUERY OP_TYPEMINQUERY OP_TYPEUPTO OP_TYPEMINUPTO OP_TYPEEXACT Matching a character string --------------------------- The OP_CHARS opcode is followed by a one-byte count and then that number of characters. If there are more than 255 characters in sequence, successive instances of OP_CHARS are used. Character classes ----------------- If there is only one character, OP_CHARS is used for a positive class, and OP_NOT for a negative one (that is, for something like [^a]). However, in UTF-8 mode, this applies only to characters with values < 128, because OP_NOT is confined to single bytes. Another set of repeating opcodes (OP_NOTSTAR etc.) are used for a repeated, negated, single-character class. The normal ones (OP_STAR etc.) are used for a repeated positive single-character class. When there's more than one character in a class and all the characters are less than 256, OP_CLASS is used for a positive class, and OP_NCLASS for a negative one. In either case, the opcode is followed by a 32-byte bit map containing a 1 bit for every character that is acceptable. The bits are counted from the least significant end of each byte. The reason for having both OP_CLASS and OP_NCLASS is so that, in UTF-8 mode, subject characters with values greater than 256 can be handled correctly. For OP_CLASS they don't match, whereas for OP_NCLASS they do. For classes containing characters with values > 255, OP_XCLASS is used. It optionally uses a bit map (if any characters lie within it), followed by a list of pairs and single characters. There is a flag character than indicates whether it's a positive or a negative class. Back references --------------- OP_REF is followed by two bytes containing the reference number. Repeating character classes and back references ----------------------------------------------- Single-character classes are handled specially (see above). This applies to OP_CLASS and OP_REF. In both cases, the repeat information follows the base item. The matching code looks at the following opcode to see if it is one of OP_CRSTAR OP_CRMINSTAR OP_CRPLUS OP_CRMINPLUS OP_CRQUERY OP_CRMINQUERY OP_CRRANGE OP_CRMINRANGE All but the last two are just single-byte items. The others are followed by four bytes of data, comprising the minimum and maximum repeat counts. Brackets and alternation ------------------------ A pair of non-capturing (round) brackets is wrapped round each expression at compile time, so alternation always happens in the context of brackets. Non-capturing brackets use the opcode OP_BRA, while capturing brackets use OP_BRA+1, OP_BRA+2, etc. [Note for North Americans: "bracket" to some English speakers, including myself, can be round, square, curly, or pointy. Hence this usage.] Originally PCRE was limited to 99 capturing brackets (so as not to use up all the opcodes). From release 3.5, there is no limit. What happens is that the first ones, up to EXTRACT_BASIC_MAX are handled with separate opcodes, as above. If there are more, the opcode is set to EXTRACT_BASIC_MAX+1, and the first operation in the bracket is OP_BRANUMBER, followed by a 2-byte bracket number. This opcode is ignored while matching, but is fished out when handling the bracket itself. (They could have all been done like this, but I was making minimal changes.) A bracket opcode is followed by two bytes which give the offset to the next alternative OP_ALT or, if there aren't any branches, to the matching KET opcode. Each OP_ALT is followed by two bytes giving the offset to the next one, or to the KET opcode. OP_KET is used for subpatterns that do not repeat indefinitely, while OP_KETRMIN and OP_KETRMAX are used for indefinite repetitions, minimally or maximally respectively. All three are followed by two bytes giving (as a positive number) the offset back to the matching BRA opcode. If a subpattern is quantified such that it is permitted to match zero times, it is preceded by one of OP_BRAZERO or OP_BRAMINZERO. These are single-byte opcodes which tell the matcher that skipping this subpattern entirely is a valid branch. A subpattern with an indefinite maximum repetition is replicated in the compiled data its minimum number of times (or once with a BRAZERO if the minimum is zero), with the final copy terminating with a KETRMIN or KETRMAX as appropriate. A subpattern with a bounded maximum repetition is replicated in a nested fashion up to the maximum number of times, with BRAZERO or BRAMINZERO before each replication after the minimum, so that, for example, (abc){2,5} is compiled as (abc)(abc)((abc)((abc)(abc)?)?)?. The 99 and 200 bracket limits do not apply to these internally generated brackets. Assertions ---------- Forward assertions are just like other subpatterns, but starting with one of the opcodes OP_ASSERT or OP_ASSERT_NOT. Backward assertions use the opcodes OP_ASSERTBACK and OP_ASSERTBACK_NOT, and the first opcode inside the assertion is OP_REVERSE, followed by a two byte count of the number of characters to move back the pointer in the subject string. When operating in UTF-8 mode, the count is a character count rather than a byte count. A separate count is present in each alternative of a lookbehind assertion, allowing them to have different fixed lengths. Once-only subpatterns --------------------- These are also just like other subpatterns, but they start with the opcode OP_ONCE. Conditional subpatterns ----------------------- These are like other subpatterns, but they start with the opcode OP_COND. If the condition is a back reference, this is stored at the start of the subpattern using the opcode OP_CREF followed by two bytes containing the reference number. If the condition is "in recursion" (coded as "(?(R)"), the same scheme is used, with a "reference number" of 0xffff. Otherwise, a conditional subpattern always starts with one of the assertions. Recursion --------- Recursion either matches the current regex, or some subexpression. The opcode OP_RECURSE is followed by an value which is the offset to the starting bracket from the start of the whole pattern. Callout ------- OP_CALLOUT is followed by one byte of data that holds a callout number in the range 0 to 255. Changing options ---------------- If any of the /i, /m, or /s options are changed within a pattern, an OP_OPT opcode is compiled, followed by one byte containing the new settings of these flags. If there are several alternatives, there is an occurrence of OP_OPT at the start of all those following the first options change, to set appropriate options for the start of the alternative. Immediately after the end of the group there is another such item to reset the flags to their previous values. A change of flag right at the very start of the pattern can be handled entirely at compile time, and so does not cause anything to be put into the compiled data. Philip Hazel August 2003 usr/doc/pcre-4.4/html/0040755000000000000000000000000007776057301013352 5ustar rootrootusr/doc/pcre-4.4/html/index.html0100644000000000000000000000734607721121074015343 0ustar rootroot PCRE specification

Perl-compatible Regular Expressions (PCRE)

The HTML documentation for PCRE comprises the following pages:

pcre   Introductory page
pcreapi   PCRE's native API
pcrebuild   Options for building PCRE
pcrecallout   The callout facility
pcrecompat   Compability with Perl
pcregrep   The pcregrep command
pcrepattern   Regular expressions supported by PCRE
pcreperform   Some comments on performance
pcreposix   The POSIX API to the PCRE library
pcresample   Description of the sample program
pcretest   The pcretest command for testing PCRE

There are also individual pages that summarize the interface for each function in the library:

pcre_compile   Compile a regular expression
pcre_config   Show build-time configuration options
pcre_copy_named_substring   Extract named substring into given buffer
pcre_copy_substring   Extract numbered substring into given buffer
pcre_exec   Match a compiled pattern to a subject string
pcre_free_substring   Free extracted substring
pcre_free_substring_list   Free list of extracted substrings
pcre_fullinfo   Extract information about a pattern
pcre_get_named_substring   Extract named substring into new memory
pcre_get_stringnumber   Convert captured string name to number
pcre_get_substring   Extract numbered substring into new memory
pcre_get_substring_list   Extract all substrings into new memory
pcre_info   Obsolete information extraction function
pcre_maketables   Build character tables in current locale
pcre_study   Study a compiled pattern
pcre_version   Return PCRE version and release date
usr/doc/pcre-4.4/html/pcre.html0100644000000000000000000001727507721121074015167 0ustar rootroot pcre specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

DESCRIPTION

The PCRE library is a set of functions that implement regular expression pattern matching using the same syntax and semantics as Perl, with just a few differences. The current implementation of PCRE (release 4.x) corresponds approximately with Perl 5.8, including support for UTF-8 encoded strings. However, this support has to be explicitly enabled; it is not the default.

PCRE is written in C and released as a C library. However, a number of people have written wrappers and interfaces of various kinds. A C++ class is included in these contributions, which can be found in the Contrib directory at the primary FTP site, which is:

ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre

Details of exactly which Perl regular expression features are and are not supported by PCRE are given in separate documents. See the pcrepattern and pcrecompat pages.

Some features of PCRE can be included, excluded, or changed when the library is built. The pcre_config() function makes it possible for a client to discover which features are available. Documentation about building PCRE for various operating systems can be found in the README file in the source distribution.


USER DOCUMENTATION

The user documentation for PCRE has been split up into a number of different sections. In the "man" format, each of these is a separate "man page". In the HTML format, each is a separate page, linked from the index page. In the plain text format, all the sections are concatenated, for ease of searching. The sections are as follows: 

  pcre              this document
  pcreapi           details of PCRE's native API
  pcrebuild         options for building PCRE
  pcrecallout       details of the callout feature
  pcrecompat        discussion of Perl compatibility
  pcregrep          description of the pcregrep command
  pcrepattern       syntax and semantics of supported
                      regular expressions
  pcreperform       discussion of performance issues
  pcreposix         the POSIX-compatible API
  pcresample        discussion of the sample program
  pcretest          the pcretest testing command

In addition, in the "man" and HTML formats, there is a short page for each library function, listing its arguments and results.


LIMITATIONS

There are some size limitations in PCRE but it is hoped that they will never in practice be relevant.

The maximum length of a compiled pattern is 65539 (sic) bytes if PCRE is compiled with the default internal linkage size of 2. If you want to process regular expressions that are truly enormous, you can compile PCRE with an internal linkage size of 3 or 4 (see the README file in the source distribution and the pcrebuild documentation for details). If these cases the limit is substantially larger. However, the speed of execution will be slower.

All values in repeating quantifiers must be less than 65536. The maximum number of capturing subpatterns is 65535.

There is no limit to the number of non-capturing subpatterns, but the maximum depth of nesting of all kinds of parenthesized subpattern, including capturing subpatterns, assertions, and other types of subpattern, is 200.

The maximum length of a subject string is the largest positive number that an integer variable can hold. However, PCRE uses recursion to handle subpatterns and indefinite repetition. This means that the available stack space may limit the size of a subject string that can be processed by certain patterns.


UTF-8 SUPPORT

Starting at release 3.3, PCRE has had some support for character strings encoded in the UTF-8 format. For release 4.0 this has been greatly extended to cover most common requirements.

In order process UTF-8 strings, you must build PCRE to include UTF-8 support in the code, and, in addition, you must call pcre_compile() with the PCRE_UTF8 option flag. When you do this, both the pattern and any subject strings that are matched against it are treated as UTF-8 strings instead of just strings of bytes.

If you compile PCRE with UTF-8 support, but do not use it at run time, the library will be a bit bigger, but the additional run time overhead is limited to testing the PCRE_UTF8 flag in several places, so should not be very large.

The following comments apply when PCRE is running in UTF-8 mode:

1. When you set the PCRE_UTF8 flag, the strings passed as patterns and subjects are checked for validity on entry to the relevant functions. If an invalid UTF-8 string is passed, an error return is given. In some situations, you may already know that your strings are valid, and therefore want to skip these checks in order to improve performance. If you set the PCRE_NO_UTF8_CHECK flag at compile time or at run time, PCRE assumes that the pattern or subject it is given (respectively) contains only valid UTF-8 codes. In this case, it does not diagnose an invalid UTF-8 string. If you pass an invalid UTF-8 string to PCRE when PCRE_NO_UTF8_CHECK is set, the results are undefined. Your program may crash.

2. In a pattern, the escape sequence \x{...}, where the contents of the braces is a string of hexadecimal digits, is interpreted as a UTF-8 character whose code number is the given hexadecimal number, for example: \x{1234}. If a non-hexadecimal digit appears between the braces, the item is not recognized. This escape sequence can be used either as a literal, or within a character class.

3. The original hexadecimal escape sequence, \xhh, matches a two-byte UTF-8 character if the value is greater than 127.

4. Repeat quantifiers apply to complete UTF-8 characters, not to individual bytes, for example: \x{100}{3}.

5. The dot metacharacter matches one UTF-8 character instead of a single byte.

6. The escape sequence \C can be used to match a single byte in UTF-8 mode, but its use can lead to some strange effects.

7. The character escapes \b, \B, \d, \D, \s, \S, \w, and \W correctly test characters of any code value, but the characters that PCRE recognizes as digits, spaces, or word characters remain the same set as before, all with values less than 256.

8. Case-insensitive matching applies only to characters whose values are less than 256. PCRE does not support the notion of "case" for higher-valued characters.

9. PCRE does not support the use of Unicode tables and properties or the Perl escapes \p, \P, and \X.


AUTHOR

Philip Hazel <ph10@cam.ac.uk>
University Computing Service,
Cambridge CB2 3QG, England.
Phone: +44 1223 334714

Last updated: 20 August 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcre_compile.html0100644000000000000000000000440207721121074016663 0ustar rootroot pcre_compile specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

pcre *pcre_compile(const char *pattern, int options, const char **errptr, int *erroffset, const unsigned char *tableptr);


DESCRIPTION

This function compiles a regular expression into an internal form. Its arguments are: 

  pattern       A zero-terminated string containing the
                  regular expression to be compiled
  options       Zero or more option bits
  errptr        Where to put an error message
  erroffset     Offset in pattern where error was found
  tableptr      Pointer to character tables, or NULL to
                  use the built-in default

The option bits are: 

  PCRE_ANCHORED         Force pattern anchoring
  PCRE_CASELESS         Do caseless matching
  PCRE_DOLLAR_ENDONLY   $ not to match newline at end
  PCRE_DOTALL           . matches anything including NL
  PCRE_EXTENDED         Ignore whitespace and # comments
  PCRE_EXTRA            PCRE extra features
                          (not much use currently)
  PCRE_MULTILINE        ^ and $ match newlines within data
  PCRE_NO_AUTO_CAPTURE  Disable numbered capturing paren-
                          theses (named ones available)
  PCRE_UNGREEDY         Invert greediness of quantifiers
  PCRE_UTF8             Run in UTF-8 mode
  PCRE_NO_UTF8_CHECK    Do not check the pattern for UTF-8
                          validity (only relevant if
                          PCRE_UTF8 is set)

PCRE must be compiled with UTF-8 support in order to use PCRE_UTF8 (or PCRE_NO_UTF8_CHECK).

The yield of the function is a pointer to a private data structure that contains the compiled pattern, or NULL if an error was detected.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_config.html0100644000000000000000000000306707721121074016506 0ustar rootroot pcre_config specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_config(int what, void *where);


DESCRIPTION

This function makes it possible for a client program to find out which optional features are available in the version of the PCRE library it is using. Its arguments are as follows: 

  what     A code specifying what information is required
  where    Points to where to put the data

The available codes are: 

  PCRE_CONFIG_LINK_SIZE    Internal link size: 2, 3, or 4
  PCRE_CONFIG_MATCH_LIMIT  Internal resource limit
  PCRE_CONFIG_NEWLINE      Value of the newline character
  PCRE_CONFIG_POSIX_MALLOC_THRESHOLD
                           Threshold of return slots, above
                             which malloc() is used by
                             the POSIX API
  PCRE_CONFIG_UTF8         Availability of UTF-8 support

The function yields 0 on success or PCRE_ERROR_BADOPTION otherwise.

There is a complete description of the PCRE native API in the pcreapi page, and a description of the POSIX API in the pcreposix page. usr/doc/pcre-4.4/html/pcre_copy_named_substring.html0100644000000000000000000000273607721121074021461 0ustar rootroot pcre_copy_named_substring specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_copy_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, char *buffer, int buffersize);


DESCRIPTION

This is a convenience function for extracting a captured substring, identified by name, into a given buffer. The arguments are: 

  code          Pattern that was successfully matched
  subject       Subject that has been successfully matched
  ovector       Offset vector that pcre_exec() used
  stringcount   Value returned by pcre_exec()
  stringname    Name of the required substring
  buffer        Buffer to receive the string
  buffersize    Size of buffer

The yield is the length of the substring, PCRE_ERROR_NOMEMORY if the buffer was too small, or PCRE_ERROR_NOSUBSTRING if the string name is invalid.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_copy_substring.html0100644000000000000000000000253307721121074020310 0ustar rootroot pcre_copy_substring specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_copy_substring(const char *subject, int *ovector, int stringcount, int stringnumber, char *buffer, int buffersize);


DESCRIPTION

This is a convenience function for extracting a captured substring into a given buffer. The arguments are: 

  subject       Subject that has been successfully matched
  ovector       Offset vector that pcre_exec() used
  stringcount   Value returned by pcre_exec()
  stringnumber  Number of the required substring
  buffer        Buffer to receive the string
  buffersize    Size of buffer

The yield is the legnth of the string, PCRE_ERROR_NOMEMORY if the buffer was too small, or PCRE_ERROR_NOSUBSTRING if the string number is invalid.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_exec.html0100644000000000000000000000357207721121074016166 0ustar rootroot pcre_exec specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_exec(const pcre *code, const pcre_extra *extra, const char *subject, int length, int startoffset, int options, int *ovector, int ovecsize);


DESCRIPTION

This function matches a compiled regular expression against a given subject string, and returns offsets to capturing subexpressions. Its arguments are: 

  code         Points to the compiled pattern
  extra        Points to an associated pcre_extra structure,
                 or is NULL
  subject      Points to the subject string
  length       Length of the subject string, in bytes
  startoffset  Offset in bytes in the subject at which to
                 start matching
  options      Option bits
  ovector      Points to a vector of ints for result offsets
  ovecsize     Size of the vector (a multiple of 3)

The options are: 

  PCRE_ANCHORED      Match only at the first position
  PCRE_NOTBOL        Subject is not the beginning of a line
  PCRE_NOTEOL        Subject is not the end of a line
  PCRE_NOTEMPTY      An empty string is not a valid match
  PCRE_NO_UTF8_CHECK Do not check the subject for UTF-8
                       validity (only relevant if PCRE_UTF8
                       was set at compile time)

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_free_substring.html0100644000000000000000000000146307721121074020260 0ustar rootroot pcre_free_substring specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

void pcre_free_substring(const char *stringptr);


DESCRIPTION

This is a convenience function for freeing the store obtained by a previous call to pcre_get_substring() or pcre_get_named_substring(). Its only argument is a pointer to the string.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_free_substring_list.html0100644000000000000000000000145707721121074021316 0ustar rootroot pcre_free_substring_list specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

void pcre_free_substring_list(const char **stringptr);


DESCRIPTION

This is a convenience function for freeing the store obtained by a previous call to pcre_get_substring_list(). Its only argument is a pointer to the list of string pointers.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_fullinfo.html0100644000000000000000000000406207721121074017053 0ustar rootroot pcre_fullinfo specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_fullinfo(const pcre *code, const pcre_extra *extra, int what, void *where);


DESCRIPTION

This function returns information about a compiled pattern. Its arguments are: 

  code    Compiled regular expression
  extra   Result of pcre_study() or NULL
  what    What information is required
  where   Where to put the information

The following information is available: 

  PCRE_INFO_BACKREFMAX     Number of highest back reference
  PCRE_INFO_CAPTURECOUNT   Number of capturing subpatterns
  PCRE_INFO_FIRSTBYTE      Fixed first byte for a match, or
                             -1 for start of string
                                or after newline, or
                             -2 otherwise
  PCRE_INFO_FIRSTTABLE     Table of first bytes
                             (after studying)
  PCRE_INFO_LASTLITERAL    Literal last byte required
  PCRE_INFO_NAMECOUNT      Number of named subpatterns
  PCRE_INFO_NAMEENTRYSIZE  Size of name table entry
  PCRE_INFO_NAMETABLE      Pointer to name table
  PCRE_INFO_OPTIONS        Options used for compilation
  PCRE_INFO_SIZE           Size of compiled pattern

The yield of the function is zero on success or: 

  PCRE_ERROR_NULL       the argument code was NULL
                        the argument where was NULL
  PCRE_ERROR_BADMAGIC   the "magic number" was not found
  PCRE_ERROR_BADOPTION  the value of what was invalid

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_get_named_substring.html0100644000000000000000000000261707721121074021264 0ustar rootroot pcre_get_named_substring specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_get_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, const char **stringptr);


DESCRIPTION

This is a convenience function for extracting a captured substring by name. The arguments are: 

  code          Compiled pattern
  subject       Subject that has been successfully matched
  ovector       Offset vector that pcre_exec() used
  stringcount   Value returned by pcre_exec()
  stringname    Name of the required substring
  stringptr     Where to put the string pointer

The yield is the length of the extracted substring, PCRE_ERROR_NOMEMORY if sufficient memory could not be obtained, or PCRE_ERROR_NOSUBSTRING if the string name is invalid.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_get_stringnumber.html0100644000000000000000000000177607721121074020624 0ustar rootroot pcre_get_stringnumber specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_get_stringnumber(const pcre *code, const char *name);


DESCRIPTION

This convenience function finds the number of a named substring capturing parenthesis in a compiled pattern. Its arguments are: 

  code    Compiled regular expression
  name    Name whose number is required

The yield of the function is the number of the parenthesis if the name is found, or PCRE_ERROR_NOSUBSTRING otherwise.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_get_substring.html0100644000000000000000000000244707721121074020121 0ustar rootroot pcre_get_substring specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_get_substring(const char *subject, int *ovector, int stringcount, int stringnumber, const char **stringptr);


DESCRIPTION

This is a convenience function for extracting a captured substring. The arguments are: 

  subject       Subject that has been successfully matched
  ovector       Offset vector that pcre_exec() used
  stringcount   Value returned by pcre_exec()
  stringnumber  Number of the required substring
  stringptr     Where to put the string pointer

The yield is the length of the substring, PCRE_ERROR_NOMEMORY if sufficient memory could not be obtained, or PCRE_ERROR_NOSUBSTRING if the string number is invalid.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_get_substring_list.html0100644000000000000000000000224307721121074021146 0ustar rootroot pcre_get_substring_list specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_get_substring_list(const char *subject, int *ovector, int stringcount, const char ***listptr);


DESCRIPTION

This is a convenience function for extracting a list of all the captured substrings. The arguments are: 

  subject       Subject that has been successfully matched
  ovector       Offset vector that pcre_exec used
  stringcount   Value returned by pcre_exec
  listptr       Where to put a pointer to the list

The yield is zero on success or PCRE_ERROR_NOMEMORY if sufficient memory could not be obtained.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_info.html0100644000000000000000000000133107721121074016164 0ustar rootroot pcre_info specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

int pcre_info(const pcre *code, int *optptr, int *firstcharptr);


DESCRIPTION

This function is obsolete. You should be using pcre_fullinfo() instead.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_maketables.html0100644000000000000000000000163507721121074017350 0ustar rootroot pcre_maketables specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

const unsigned char *pcre_maketables(void);


DESCRIPTION

This function builds a set of character tables which can be passed to pcre_compile() to override PCRE's internal, built-in tables (which were made by pcre_maketables() when PCRE was compiled). You might want to do this if you are using a non-standard locale. The function yields a pointer to the tables.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_study.html0100644000000000000000000000240207721121074016401 0ustar rootroot pcre_study specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

pcre_extra *pcre_study(const pcre *code, int options, const char **errptr);


DESCRIPTION

This function studies a compiled pattern, to see if additional information can be extracted that might speed up matching. Its arguments are: 

  code       A compiled regular expression
  options    Options for pcre_study()
  errptr     Where to put an error message

If the function returns NULL, either it could not find any additional information, or there was an error. You can tell the difference by looking at the error value. It is NULL in first case.

There are currently no options defined; the value of the second argument should always be zero.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcre_version.html0100644000000000000000000000127707721121074016727 0ustar rootroot pcre_version specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.

SYNOPSIS

#include <pcre.h>

char *pcre_version(void);


DESCRIPTION

This function returns a character string that gives the version number of the PCRE library, and its date of release.

There is a complete description of the PCRE API in the pcreapi page. usr/doc/pcre-4.4/html/pcreapi.html0100644000000000000000000013730207721121074015653 0ustar rootroot pcreapi specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


SYNOPSIS OF PCRE API

#include <pcre.h>

pcre *pcre_compile(const char *pattern, int options, const char **errptr, int *erroffset, const unsigned char *tableptr);

pcre_extra *pcre_study(const pcre *code, int options, const char **errptr);

int pcre_exec(const pcre *code, const pcre_extra *extra, const char *subject, int length, int startoffset, int options, int *ovector, int ovecsize);

int pcre_copy_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, char *buffer, int buffersize);

int pcre_copy_substring(const char *subject, int *ovector, int stringcount, int stringnumber, char *buffer, int buffersize);

int pcre_get_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, const char **stringptr);

int pcre_get_stringnumber(const pcre *code, const char *name);

int pcre_get_substring(const char *subject, int *ovector, int stringcount, int stringnumber, const char **stringptr);

int pcre_get_substring_list(const char *subject, int *ovector, int stringcount, const char ***listptr);

void pcre_free_substring(const char *stringptr);

void pcre_free_substring_list(const char **stringptr);

const unsigned char *pcre_maketables(void);

int pcre_fullinfo(const pcre *code, const pcre_extra *extra, int what, void *where);

int pcre_info(const pcre *code, int *optptr, int *firstcharptr);

int pcre_config(int what, void *where);

char *pcre_version(void);

void *(*pcre_malloc)(size_t);

void (*pcre_free)(void *);

int (*pcre_callout)(pcre_callout_block *);


PCRE API

PCRE has its own native API, which is described in this document. There is also a set of wrapper functions that correspond to the POSIX regular expression API. These are described in the pcreposix documentation.

The native API function prototypes are defined in the header file pcre.h, and on Unix systems the library itself is called libpcre.a, so can be accessed by adding -lpcre to the command for linking an application which calls it. The header file defines the macros PCRE_MAJOR and PCRE_MINOR to contain the major and minor release numbers for the library. Applications can use these to include support for different releases.

The functions pcre_compile(), pcre_study(), and pcre_exec() are used for compiling and matching regular expressions. A sample program that demonstrates the simplest way of using them is given in the file pcredemo.c. The pcresample documentation describes how to run it.

There are convenience functions for extracting captured substrings from a matched subject string. They are: 

  pcre_copy_substring()
  pcre_copy_named_substring()
  pcre_get_substring()
  pcre_get_named_substring()
  pcre_get_substring_list()

pcre_free_substring() and pcre_free_substring_list() are also provided, to free the memory used for extracted strings.

The function pcre_maketables() is used (optionally) to build a set of character tables in the current locale for passing to pcre_compile().

The function pcre_fullinfo() is used to find out information about a compiled pattern; pcre_info() is an obsolete version which returns only some of the available information, but is retained for backwards compatibility. The function pcre_version() returns a pointer to a string containing the version of PCRE and its date of release.

The global variables pcre_malloc and pcre_free initially contain the entry points of the standard malloc() and free() functions respectively. PCRE calls the memory management functions via these variables, so a calling program can replace them if it wishes to intercept the calls. This should be done before calling any PCRE functions.

The global variable pcre_callout initially contains NULL. It can be set by the caller to a "callout" function, which PCRE will then call at specified points during a matching operation. Details are given in the pcrecallout documentation.


MULTITHREADING

The PCRE functions can be used in multi-threading applications, with the proviso that the memory management functions pointed to by pcre_malloc and pcre_free, and the callout function pointed to by pcre_callout, are shared by all threads.

The compiled form of a regular expression is not altered during matching, so the same compiled pattern can safely be used by several threads at once.


CHECKING BUILD-TIME OPTIONS

int pcre_config(int what, void *where);

The function pcre_config() makes it possible for a PCRE client to discover which optional features have been compiled into the PCRE library. The pcrebuild documentation has more details about these optional features.

The first argument for pcre_config() is an integer, specifying which information is required; the second argument is a pointer to a variable into which the information is placed. The following information is available: 

  PCRE_CONFIG_UTF8

The output is an integer that is set to one if UTF-8 support is available; otherwise it is set to zero. 

  PCRE_CONFIG_NEWLINE

The output is an integer that is set to the value of the code that is used for the newline character. It is either linefeed (10) or carriage return (13), and should normally be the standard character for your operating system. 

  PCRE_CONFIG_LINK_SIZE

The output is an integer that contains the number of bytes used for internal linkage in compiled regular expressions. The value is 2, 3, or 4. Larger values allow larger regular expressions to be compiled, at the expense of slower matching. The default value of 2 is sufficient for all but the most massive patterns, since it allows the compiled pattern to be up to 64K in size. 

  PCRE_CONFIG_POSIX_MALLOC_THRESHOLD

The output is an integer that contains the threshold above which the POSIX interface uses malloc() for output vectors. Further details are given in the pcreposix documentation. 

  PCRE_CONFIG_MATCH_LIMIT

The output is an integer that gives the default limit for the number of internal matching function calls in a pcre_exec() execution. Further details are given with pcre_exec() below.


COMPILING A PATTERN

pcre *pcre_compile(const char *pattern, int options, const char **errptr, int *erroffset, const unsigned char *tableptr);

The function pcre_compile() is called to compile a pattern into an internal form. The pattern is a C string terminated by a binary zero, and is passed in the argument pattern. A pointer to a single block of memory that is obtained via pcre_malloc is returned. This contains the compiled code and related data. The pcre type is defined for the returned block; this is a typedef for a structure whose contents are not externally defined. It is up to the caller to free the memory when it is no longer required.

Although the compiled code of a PCRE regex is relocatable, that is, it does not depend on memory location, the complete pcre data block is not fully relocatable, because it contains a copy of the tableptr argument, which is an address (see below).

The options argument contains independent bits that affect the compilation. It should be zero if no options are required. Some of the options, in particular, those that are compatible with Perl, can also be set and unset from within the pattern (see the detailed description of regular expressions in the pcrepattern documentation). For these options, the contents of the options argument specifies their initial settings at the start of compilation and execution. The PCRE_ANCHORED option can be set at the time of matching as well as at compile time.

If errptr is NULL, pcre_compile() returns NULL immediately. Otherwise, if compilation of a pattern fails, pcre_compile() returns NULL, and sets the variable pointed to by errptr to point to a textual error message. The offset from the start of the pattern to the character where the error was discovered is placed in the variable pointed to by erroffset, which must not be NULL. If it is, an immediate error is given.

If the final argument, tableptr, is NULL, PCRE uses a default set of character tables which are built when it is compiled, using the default C locale. Otherwise, tableptr must be the result of a call to pcre_maketables(). See the section on locale support below.

This code fragment shows a typical straightforward call to pcre_compile(): 

  pcre *re;
  const char *error;
  int erroffset;
  re = pcre_compile(
    "^A.*Z",          /* the pattern */
    0,                /* default options */
    &error,           /* for error message */
    &erroffset,       /* for error offset */
    NULL);            /* use default character tables */

The following option bits are defined: 

  PCRE_ANCHORED

If this bit is set, the pattern is forced to be "anchored", that is, it is constrained to match only at the first matching point in the string which is being searched (the "subject string"). This effect can also be achieved by appropriate constructs in the pattern itself, which is the only way to do it in Perl. 

  PCRE_CASELESS

If this bit is set, letters in the pattern match both upper and lower case letters. It is equivalent to Perl's /i option, and it can be changed within a pattern by a (?i) option setting. 

  PCRE_DOLLAR_ENDONLY

If this bit is set, a dollar metacharacter in the pattern matches only at the end of the subject string. Without this option, a dollar also matches immediately before the final character if it is a newline (but not before any other newlines). The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is set. There is no equivalent to this option in Perl, and no way to set it within a pattern. 

  PCRE_DOTALL

If this bit is set, a dot metacharater in the pattern matches all characters, including newlines. Without it, newlines are excluded. This option is equivalent to Perl's /s option, and it can be changed within a pattern by a (?s) option setting. A negative class such as [^a] always matches a newline character, independent of the setting of this option. 

  PCRE_EXTENDED

If this bit is set, whitespace data characters in the pattern are totally ignored except when escaped or inside a character class. Whitespace does not include the VT character (code 11). In addition, characters between an unescaped # outside a character class and the next newline character, inclusive, are also ignored. This is equivalent to Perl's /x option, and it can be changed within a pattern by a (?x) option setting.

This option makes it possible to include comments inside complicated patterns. Note, however, that this applies only to data characters. Whitespace characters may never appear within special character sequences in a pattern, for example within the sequence (?( which introduces a conditional subpattern. 

  PCRE_EXTRA

This option was invented in order to turn on additional functionality of PCRE that is incompatible with Perl, but it is currently of very little use. When set, any backslash in a pattern that is followed by a letter that has no special meaning causes an error, thus reserving these combinations for future expansion. By default, as in Perl, a backslash followed by a letter with no special meaning is treated as a literal. There are at present no other features controlled by this option. It can also be set by a (?X) option setting within a pattern. 

  PCRE_MULTILINE

By default, PCRE treats the subject string as consisting of a single "line" of characters (even if it actually contains several newlines). The "start of line" metacharacter (^) matches only at the start of the string, while the "end of line" metacharacter ($) matches only at the end of the string, or before a terminating newline (unless PCRE_DOLLAR_ENDONLY is set). This is the same as Perl.

When PCRE_MULTILINE it is set, the "start of line" and "end of line" constructs match immediately following or immediately before any newline in the subject string, respectively, as well as at the very start and end. This is equivalent to Perl's /m option, and it can be changed within a pattern by a (?m) option setting. If there are no "\n" characters in a subject string, or no occurrences of ^ or $ in a pattern, setting PCRE_MULTILINE has no effect. 

  PCRE_NO_AUTO_CAPTURE

If this option is set, it disables the use of numbered capturing parentheses in the pattern. Any opening parenthesis that is not followed by ? behaves as if it were followed by ?: but named parentheses can still be used for capturing (and they acquire numbers in the usual way). There is no equivalent of this option in Perl. 

  PCRE_UNGREEDY

This option inverts the "greediness" of the quantifiers so that they are not greedy by default, but become greedy if followed by "?". It is not compatible with Perl. It can also be set by a (?U) option setting within the pattern. 

  PCRE_UTF8

This option causes PCRE to regard both the pattern and the subject as strings of UTF-8 characters instead of single-byte character strings. However, it is available only if PCRE has been built to include UTF-8 support. If not, the use of this option provokes an error. Details of how this option changes the behaviour of PCRE are given in the section on UTF-8 support in the main pcre page. 

  PCRE_NO_UTF8_CHECK

When PCRE_UTF8 is set, the validity of the pattern as a UTF-8 string is automatically checked. If an invalid UTF-8 sequence of bytes is found, pcre_compile() returns an error. If you already know that your pattern is valid, and you want to skip this check for performance reasons, you can set the PCRE_NO_UTF8_CHECK option. When it is set, the effect of passing an invalid UTF-8 string as a pattern is undefined. It may cause your program to crash. Note that there is a similar option for suppressing the checking of subject strings passed to pcre_exec().


STUDYING A PATTERN

pcre_extra *pcre_study(const pcre *code, int options, const char **errptr);

When a pattern is going to be used several times, it is worth spending more time analyzing it in order to speed up the time taken for matching. The function pcre_study() takes a pointer to a compiled pattern as its first argument. If studing the pattern produces additional information that will help speed up matching, pcre_study() returns a pointer to a pcre_extra block, in which the study_data field points to the results of the study.

The returned value from a pcre_study() can be passed directly to pcre_exec(). However, the pcre_extra block also contains other fields that can be set by the caller before the block is passed; these are described below. If studying the pattern does not produce any additional information, pcre_study() returns NULL. In that circumstance, if the calling program wants to pass some of the other fields to pcre_exec(), it must set up its own pcre_extra block.

The second argument contains option bits. At present, no options are defined for pcre_study(), and this argument should always be zero.

The third argument for pcre_study() is a pointer for an error message. If studying succeeds (even if no data is returned), the variable it points to is set to NULL. Otherwise it points to a textual error message. You should therefore test the error pointer for NULL after calling pcre_study(), to be sure that it has run successfully.

This is a typical call to pcre_study(): 

  pcre_extra *pe;
  pe = pcre_study(
    re,             /* result of pcre_compile() */
    0,              /* no options exist */
    &error);        /* set to NULL or points to a message */

At present, studying a pattern is useful only for non-anchored patterns that do not have a single fixed starting character. A bitmap of possible starting characters is created.


LOCALE SUPPORT

PCRE handles caseless matching, and determines whether characters are letters, digits, or whatever, by reference to a set of tables. When running in UTF-8 mode, this applies only to characters with codes less than 256. The library contains a default set of tables that is created in the default C locale when PCRE is compiled. This is used when the final argument of pcre_compile() is NULL, and is sufficient for many applications.

An alternative set of tables can, however, be supplied. Such tables are built by calling the pcre_maketables() function, which has no arguments, in the relevant locale. The result can then be passed to pcre_compile() as often as necessary. For example, to build and use tables that are appropriate for the French locale (where accented characters with codes greater than 128 are treated as letters), the following code could be used: 

  setlocale(LC_CTYPE, "fr");
  tables = pcre_maketables();
  re = pcre_compile(..., tables);

The tables are built in memory that is obtained via pcre_malloc. The pointer that is passed to pcre_compile is saved with the compiled pattern, and the same tables are used via this pointer by pcre_study() and pcre_exec(). Thus, for any single pattern, compilation, studying and matching all happen in the same locale, but different patterns can be compiled in different locales. It is the caller's responsibility to ensure that the memory containing the tables remains available for as long as it is needed.


INFORMATION ABOUT A PATTERN

int pcre_fullinfo(const pcre *code, const pcre_extra *extra, int what, void *where);

The pcre_fullinfo() function returns information about a compiled pattern. It replaces the obsolete pcre_info() function, which is nevertheless retained for backwards compability (and is documented below).

The first argument for pcre_fullinfo() is a pointer to the compiled pattern. The second argument is the result of pcre_study(), or NULL if the pattern was not studied. The third argument specifies which piece of information is required, and the fourth argument is a pointer to a variable to receive the data. The yield of the function is zero for success, or one of the following negative numbers: 

  PCRE_ERROR_NULL       the argument code was NULL
                        the argument where was NULL
  PCRE_ERROR_BADMAGIC   the "magic number" was not found
  PCRE_ERROR_BADOPTION  the value of what was invalid

Here is a typical call of pcre_fullinfo(), to obtain the length of the compiled pattern: 

  int rc;
  unsigned long int length;
  rc = pcre_fullinfo(
    re,               /* result of pcre_compile() */
    pe,               /* result of pcre_study(), or NULL */
    PCRE_INFO_SIZE,   /* what is required */
    &length);         /* where to put the data */

The possible values for the third argument are defined in pcre.h, and are as follows: 

  PCRE_INFO_BACKREFMAX

Return the number of the highest back reference in the pattern. The fourth argument should point to an int variable. Zero is returned if there are no back references. 

  PCRE_INFO_CAPTURECOUNT

Return the number of capturing subpatterns in the pattern. The fourth argument should point to an \fbint\fR variable. 

  PCRE_INFO_FIRSTBYTE

Return information about the first byte of any matched string, for a non-anchored pattern. (This option used to be called PCRE_INFO_FIRSTCHAR; the old name is still recognized for backwards compatibility.)

If there is a fixed first byte, e.g. from a pattern such as (cat|cow|coyote), it is returned in the integer pointed to by where. Otherwise, if either

(a) the pattern was compiled with the PCRE_MULTILINE option, and every branch starts with "^", or

(b) every branch of the pattern starts with ".*" and PCRE_DOTALL is not set (if it were set, the pattern would be anchored),

-1 is returned, indicating that the pattern matches only at the start of a subject string or after any newline within the string. Otherwise -2 is returned. For anchored patterns, -2 is returned. 

  PCRE_INFO_FIRSTTABLE

If the pattern was studied, and this resulted in the construction of a 256-bit table indicating a fixed set of bytes for the first byte in any matching string, a pointer to the table is returned. Otherwise NULL is returned. The fourth argument should point to an unsigned char * variable. 

  PCRE_INFO_LASTLITERAL

Return the value of the rightmost literal byte that must exist in any matched string, other than at its start, if such a byte has been recorded. The fourth argument should point to an int variable. If there is no such byte, -1 is returned. For anchored patterns, a last literal byte is recorded only if it follows something of variable length. For example, for the pattern /^a\d+z\d+/ the returned value is "z", but for /^a\dz\d/ the returned value is -1. 

  PCRE_INFO_NAMECOUNT
  PCRE_INFO_NAMEENTRYSIZE
  PCRE_INFO_NAMETABLE

PCRE supports the use of named as well as numbered capturing parentheses. The names are just an additional way of identifying the parentheses, which still acquire a number. A caller that wants to extract data from a named subpattern must convert the name to a number in order to access the correct pointers in the output vector (described with pcre_exec() below). In order to do this, it must first use these three values to obtain the name-to-number mapping table for the pattern.

The map consists of a number of fixed-size entries. PCRE_INFO_NAMECOUNT gives the number of entries, and PCRE_INFO_NAMEENTRYSIZE gives the size of each entry; both of these return an int value. The entry size depends on the length of the longest name. PCRE_INFO_NAMETABLE returns a pointer to the first entry of the table (a pointer to char). The first two bytes of each entry are the number of the capturing parenthesis, most significant byte first. The rest of the entry is the corresponding name, zero terminated. The names are in alphabetical order. For example, consider the following pattern (assume PCRE_EXTENDED is set, so white space - including newlines - is ignored): 

  (?P<date> (?P<year>(\d\d)?\d\d) -
  (?P<month>\d\d) - (?P<day>\d\d) )

There are four named subpatterns, so the table has four entries, and each entry in the table is eight bytes long. The table is as follows, with non-printing bytes shows in hex, and undefined bytes shown as ??: 

  00 01 d  a  t  e  00 ??
  00 05 d  a  y  00 ?? ??
  00 04 m  o  n  t  h  00
  00 02 y  e  a  r  00 ??

When writing code to extract data from named subpatterns, remember that the length of each entry may be different for each compiled pattern. 

  PCRE_INFO_OPTIONS

Return a copy of the options with which the pattern was compiled. The fourth argument should point to an unsigned long int variable. These option bits are those specified in the call to pcre_compile(), modified by any top-level option settings within the pattern itself.

A pattern is automatically anchored by PCRE if all of its top-level alternatives begin with one of the following: 

  ^     unless PCRE_MULTILINE is set
  \A    always
  \G    always
  .*    if PCRE_DOTALL is set and there are no back
          references to the subpattern in which .* appears

For such patterns, the PCRE_ANCHORED bit is set in the options returned by pcre_fullinfo(). 

  PCRE_INFO_SIZE

Return the size of the compiled pattern, that is, the value that was passed as the argument to pcre_malloc() when PCRE was getting memory in which to place the compiled data. The fourth argument should point to a size_t variable. 

  PCRE_INFO_STUDYSIZE

Returns the size of the data block pointed to by the study_data field in a pcre_extra block. That is, it is the value that was passed to pcre_malloc() when PCRE was getting memory into which to place the data created by pcre_study(). The fourth argument should point to a size_t variable.


OBSOLETE INFO FUNCTION

int pcre_info(const pcre *code, int *optptr, int *firstcharptr);

The pcre_info() function is now obsolete because its interface is too restrictive to return all the available data about a compiled pattern. New programs should use pcre_fullinfo() instead. The yield of pcre_info() is the number of capturing subpatterns, or one of the following negative numbers: 

  PCRE_ERROR_NULL       the argument code was NULL
  PCRE_ERROR_BADMAGIC   the "magic number" was not found

If the optptr argument is not NULL, a copy of the options with which the pattern was compiled is placed in the integer it points to (see PCRE_INFO_OPTIONS above).

If the pattern is not anchored and the firstcharptr argument is not NULL, it is used to pass back information about the first character of any matched string (see PCRE_INFO_FIRSTBYTE above).


MATCHING A PATTERN

int pcre_exec(const pcre *code, const pcre_extra *extra, const char *subject, int length, int startoffset, int options, int *ovector, int ovecsize);

The function pcre_exec() is called to match a subject string against a pre-compiled pattern, which is passed in the code argument. If the pattern has been studied, the result of the study should be passed in the extra argument.

Here is an example of a simple call to pcre_exec(): 

  int rc;
  int ovector[30];
  rc = pcre_exec(
    re,             /* result of pcre_compile() */
    NULL,           /* we didn't study the pattern */
    "some string",  /* the subject string */
    11,             /* the length of the subject string */
    0,              /* start at offset 0 in the subject */
    0,              /* default options */
    ovector,        /* vector for substring information */
    30);            /* number of elements in the vector */

If the extra argument is not NULL, it must point to a pcre_extra data block. The pcre_study() function returns such a block (when it doesn't return NULL), but you can also create one for yourself, and pass additional information in it. The fields in the block are as follows: 

  unsigned long int flags;
  void *study_data;
  unsigned long int match_limit;
  void *callout_data;

The flags field is a bitmap that specifies which of the other fields are set. The flag bits are: 

  PCRE_EXTRA_STUDY_DATA
  PCRE_EXTRA_MATCH_LIMIT
  PCRE_EXTRA_CALLOUT_DATA

Other flag bits should be set to zero. The study_data field is set in the pcre_extra block that is returned by pcre_study(), together with the appropriate flag bit. You should not set this yourself, but you can add to the block by setting the other fields.

The match_limit field provides a means of preventing PCRE from using up a vast amount of resources when running patterns that are not going to match, but which have a very large number of possibilities in their search trees. The classic example is the use of nested unlimited repeats. Internally, PCRE uses a function called match() which it calls repeatedly (sometimes recursively). The limit is imposed on the number of times this function is called during a match, which has the effect of limiting the amount of recursion and backtracking that can take place. For patterns that are not anchored, the count starts from zero for each position in the subject string.

The default limit for the library can be set when PCRE is built; the default default is 10 million, which handles all but the most extreme cases. You can reduce the default by suppling pcre_exec() with a \fRpcre_extra\fR block in which match_limit is set to a smaller value, and PCRE_EXTRA_MATCH_LIMIT is set in the flags field. If the limit is exceeded, pcre_exec() returns PCRE_ERROR_MATCHLIMIT.

The pcre_callout field is used in conjunction with the "callout" feature, which is described in the pcrecallout documentation.

The PCRE_ANCHORED option can be passed in the options argument, whose unused bits must be zero. This limits pcre_exec() to matching at the first matching position. However, if a pattern was compiled with PCRE_ANCHORED, or turned out to be anchored by virtue of its contents, it cannot be made unachored at matching time.

When PCRE_UTF8 was set at compile time, the validity of the subject as a UTF-8 string is automatically checked. If an invalid UTF-8 sequence of bytes is found, pcre_exec() returns the error PCRE_ERROR_BADUTF8. If you already know that your subject is valid, and you want to skip this check for performance reasons, you can set the PCRE_NO_UTF8_CHECK option when calling pcre_exec(). When this option is set, the effect of passing an invalid UTF-8 string as a subject is undefined. It may cause your program to crash.

There are also three further options that can be set only at matching time: 

  PCRE_NOTBOL

The first character of the string is not the beginning of a line, so the circumflex metacharacter should not match before it. Setting this without PCRE_MULTILINE (at compile time) causes circumflex never to match. 

  PCRE_NOTEOL

The end of the string is not the end of a line, so the dollar metacharacter should not match it nor (except in multiline mode) a newline immediately before it. Setting this without PCRE_MULTILINE (at compile time) causes dollar never to match. 

  PCRE_NOTEMPTY

An empty string is not considered to be a valid match if this option is set. If there are alternatives in the pattern, they are tried. If all the alternatives match the empty string, the entire match fails. For example, if the pattern 

  a?b?

is applied to a string not beginning with "a" or "b", it matches the empty string at the start of the subject. With PCRE_NOTEMPTY set, this match is not valid, so PCRE searches further into the string for occurrences of "a" or "b".

Perl has no direct equivalent of PCRE_NOTEMPTY, but it does make a special case of a pattern match of the empty string within its split() function, and when using the /g modifier. It is possible to emulate Perl's behaviour after matching a null string by first trying the match again at the same offset with PCRE_NOTEMPTY set, and then if that fails by advancing the starting offset (see below) and trying an ordinary match again.

The subject string is passed to pcre_exec() as a pointer in subject, a length in length, and a starting offset in startoffset. Unlike the pattern string, the subject may contain binary zero bytes. When the starting offset is zero, the search for a match starts at the beginning of the subject, and this is by far the most common case.

If the pattern was compiled with the PCRE_UTF8 option, the subject must be a sequence of bytes that is a valid UTF-8 string. If an invalid UTF-8 string is passed, PCRE's behaviour is not defined.

A non-zero starting offset is useful when searching for another match in the same subject by calling pcre_exec() again after a previous success. Setting startoffset differs from just passing over a shortened string and setting PCRE_NOTBOL in the case of a pattern that begins with any kind of lookbehind. For example, consider the pattern 

  \Biss\B

which finds occurrences of "iss" in the middle of words. (\B matches only if the current position in the subject is not a word boundary.) When applied to the string "Mississipi" the first call to pcre_exec() finds the first occurrence. If pcre_exec() is called again with just the remainder of the subject, namely "issipi", it does not match, because \B is always false at the start of the subject, which is deemed to be a word boundary. However, if pcre_exec() is passed the entire string again, but with startoffset set to 4, it finds the second occurrence of "iss" because it is able to look behind the starting point to discover that it is preceded by a letter.

If a non-zero starting offset is passed when the pattern is anchored, one attempt to match at the given offset is tried. This can only succeed if the pattern does not require the match to be at the start of the subject.

In general, a pattern matches a certain portion of the subject, and in addition, further substrings from the subject may be picked out by parts of the pattern. Following the usage in Jeffrey Friedl's book, this is called "capturing" in what follows, and the phrase "capturing subpattern" is used for a fragment of a pattern that picks out a substring. PCRE supports several other kinds of parenthesized subpattern that do not cause substrings to be captured.

Captured substrings are returned to the caller via a vector of integer offsets whose address is passed in ovector. The number of elements in the vector is passed in ovecsize. The first two-thirds of the vector is used to pass back captured substrings, each substring using a pair of integers. The remaining third of the vector is used as workspace by pcre_exec() while matching capturing subpatterns, and is not available for passing back information. The length passed in ovecsize should always be a multiple of three. If it is not, it is rounded down.

When a match has been successful, information about captured substrings is returned in pairs of integers, starting at the beginning of ovector, and continuing up to two-thirds of its length at the most. The first element of a pair is set to the offset of the first character in a substring, and the second is set to the offset of the first character after the end of a substring. The first pair, ovector[0] and ovector[1], identify the portion of the subject string matched by the entire pattern. The next pair is used for the first capturing subpattern, and so on. The value returned by pcre_exec() is the number of pairs that have been set. If there are no capturing subpatterns, the return value from a successful match is 1, indicating that just the first pair of offsets has been set.

Some convenience functions are provided for extracting the captured substrings as separate strings. These are described in the following section.

It is possible for an capturing subpattern number n+1 to match some part of the subject when subpattern n has not been used at all. For example, if the string "abc" is matched against the pattern (a|(z))(bc) subpatterns 1 and 3 are matched, but 2 is not. When this happens, both offset values corresponding to the unused subpattern are set to -1.

If a capturing subpattern is matched repeatedly, it is the last portion of the string that it matched that gets returned.

If the vector is too small to hold all the captured substrings, it is used as far as possible (up to two-thirds of its length), and the function returns a value of zero. In particular, if the substring offsets are not of interest, pcre_exec() may be called with ovector passed as NULL and ovecsize as zero. However, if the pattern contains back references and the ovector isn't big enough to remember the related substrings, PCRE has to get additional memory for use during matching. Thus it is usually advisable to supply an ovector.

Note that pcre_info() can be used to find out how many capturing subpatterns there are in a compiled pattern. The smallest size for ovector that will allow for n captured substrings, in addition to the offsets of the substring matched by the whole pattern, is (n+1)*3.

If pcre_exec() fails, it returns a negative number. The following are defined in the header file: 

  PCRE_ERROR_NOMATCH        (-1)

The subject string did not match the pattern. 

  PCRE_ERROR_NULL           (-2)

Either code or subject was passed as NULL, or ovector was NULL and ovecsize was not zero. 

  PCRE_ERROR_BADOPTION      (-3)

An unrecognized bit was set in the options argument. 

  PCRE_ERROR_BADMAGIC       (-4)

PCRE stores a 4-byte "magic number" at the start of the compiled code, to catch the case when it is passed a junk pointer. This is the error it gives when the magic number isn't present. 

  PCRE_ERROR_UNKNOWN_NODE   (-5)

While running the pattern match, an unknown item was encountered in the compiled pattern. This error could be caused by a bug in PCRE or by overwriting of the compiled pattern. 

  PCRE_ERROR_NOMEMORY       (-6)

If a pattern contains back references, but the ovector that is passed to pcre_exec() is not big enough to remember the referenced substrings, PCRE gets a block of memory at the start of matching to use for this purpose. If the call via pcre_malloc() fails, this error is given. The memory is freed at the end of matching. 

  PCRE_ERROR_NOSUBSTRING    (-7)

This error is used by the pcre_copy_substring(), pcre_get_substring(), and pcre_get_substring_list() functions (see below). It is never returned by pcre_exec(). 

  PCRE_ERROR_MATCHLIMIT     (-8)

The recursion and backtracking limit, as specified by the match_limit field in a pcre_extra structure (or defaulted) was reached. See the description above. 

  PCRE_ERROR_CALLOUT        (-9)

This error is never generated by pcre_exec() itself. It is provided for use by callout functions that want to yield a distinctive error code. See the pcrecallout documentation for details. 

  PCRE_ERROR_BADUTF8       (-10)

A string that contains an invalid UTF-8 byte sequence was passed as a subject.


EXTRACTING CAPTURED SUBSTRINGS BY NUMBER

int pcre_copy_substring(const char *subject, int *ovector, int stringcount, int stringnumber, char *buffer, int buffersize);

int pcre_get_substring(const char *subject, int *ovector, int stringcount, int stringnumber, const char **stringptr);

int pcre_get_substring_list(const char *subject, int *ovector, int stringcount, const char ***listptr);

Captured substrings can be accessed directly by using the offsets returned by pcre_exec() in ovector. For convenience, the functions pcre_copy_substring(), pcre_get_substring(), and pcre_get_substring_list() are provided for extracting captured substrings as new, separate, zero-terminated strings. These functions identify substrings by number. The next section describes functions for extracting named substrings. A substring that contains a binary zero is correctly extracted and has a further zero added on the end, but the result is not, of course, a C string.

The first three arguments are the same for all three of these functions: subject is the subject string which has just been successfully matched, ovector is a pointer to the vector of integer offsets that was passed to pcre_exec(), and stringcount is the number of substrings that were captured by the match, including the substring that matched the entire regular expression. This is the value returned by pcre_exec if it is greater than zero. If pcre_exec() returned zero, indicating that it ran out of space in ovector, the value passed as stringcount should be the size of the vector divided by three.

The functions pcre_copy_substring() and pcre_get_substring() extract a single substring, whose number is given as stringnumber. A value of zero extracts the substring that matched the entire pattern, while higher values extract the captured substrings. For pcre_copy_substring(), the string is placed in buffer, whose length is given by buffersize, while for pcre_get_substring() a new block of memory is obtained via pcre_malloc, and its address is returned via stringptr. The yield of the function is the length of the string, not including the terminating zero, or one of 

  PCRE_ERROR_NOMEMORY       (-6)

The buffer was too small for pcre_copy_substring(), or the attempt to get memory failed for pcre_get_substring(). 

  PCRE_ERROR_NOSUBSTRING    (-7)

There is no substring whose number is stringnumber.

The pcre_get_substring_list() function extracts all available substrings and builds a list of pointers to them. All this is done in a single block of memory which is obtained via pcre_malloc. The address of the memory block is returned via listptr, which is also the start of the list of string pointers. The end of the list is marked by a NULL pointer. The yield of the function is zero if all went well, or 

  PCRE_ERROR_NOMEMORY       (-6)

if the attempt to get the memory block failed.

When any of these functions encounter a substring that is unset, which can happen when capturing subpattern number n+1 matches some part of the subject, but subpattern n has not been used at all, they return an empty string. This can be distinguished from a genuine zero-length substring by inspecting the appropriate offset in ovector, which is negative for unset substrings.

The two convenience functions pcre_free_substring() and pcre_free_substring_list() can be used to free the memory returned by a previous call of pcre_get_substring() or pcre_get_substring_list(), respectively. They do nothing more than call the function pointed to by pcre_free, which of course could be called directly from a C program. However, PCRE is used in some situations where it is linked via a special interface to another programming language which cannot use pcre_free directly; it is for these cases that the functions are provided.


EXTRACTING CAPTURED SUBSTRINGS BY NAME

int pcre_copy_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, char *buffer, int buffersize);

int pcre_get_stringnumber(const pcre *code, const char *name);

int pcre_get_named_substring(const pcre *code, const char *subject, int *ovector, int stringcount, const char *stringname, const char **stringptr);

To extract a substring by name, you first have to find associated number. This can be done by calling pcre_get_stringnumber(). The first argument is the compiled pattern, and the second is the name. For example, for this pattern 

  ab(?<xxx>\d+)...

the number of the subpattern called "xxx" is 1. Given the number, you can then extract the substring directly, or use one of the functions described in the previous section. For convenience, there are also two functions that do the whole job.

Most of the arguments of pcre_copy_named_substring() and pcre_get_named_substring() are the same as those for the functions that extract by number, and so are not re-described here. There are just two differences.

First, instead of a substring number, a substring name is given. Second, there is an extra argument, given at the start, which is a pointer to the compiled pattern. This is needed in order to gain access to the name-to-number translation table.

These functions call pcre_get_stringnumber(), and if it succeeds, they then call pcre_copy_substring() or pcre_get_substring(), as appropriate.

Last updated: 20 August 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcrebuild.html0100644000000000000000000001242607721121074016200 0ustar rootroot pcrebuild specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


PCRE BUILD-TIME OPTIONS

This document describes the optional features of PCRE that can be selected when the library is compiled. They are all selected, or deselected, by providing options to the configure script which is run before the make command. The complete list of options for configure (which includes the standard ones such as the selection of the installation directory) can be obtained by running 

  ./configure --help

The following sections describe certain options whose names begin with --enable or --disable. These settings specify changes to the defaults for the configure command. Because of the way that configure works, --enable and --disable always come in pairs, so the complementary option always exists as well, but as it specifies the default, it is not described.


UTF-8 SUPPORT

To build PCRE with support for UTF-8 character strings, add 

  --enable-utf8

to the configure command. Of itself, this does not make PCRE treat strings as UTF-8. As well as compiling PCRE with this option, you also have have to set the PCRE_UTF8 option when you call the pcre_compile() function.


CODE VALUE OF NEWLINE

By default, PCRE treats character 10 (linefeed) as the newline character. This is the normal newline character on Unix-like systems. You can compile PCRE to use character 13 (carriage return) instead by adding 

  --enable-newline-is-cr

to the configure command. For completeness there is also a --enable-newline-is-lf option, which explicitly specifies linefeed as the newline character.


BUILDING SHARED AND STATIC LIBRARIES

The PCRE building process uses libtool to build both shared and static Unix libraries by default. You can suppress one of these by adding one of 

  --disable-shared
  --disable-static

to the configure command, as required.


POSIX MALLOC USAGE

When PCRE is called through the POSIX interface (see the pcreposix documentation), additional working storage is required for holding the pointers to capturing substrings because PCRE requires three integers per substring, whereas the POSIX interface provides only two. If the number of expected substrings is small, the wrapper function uses space on the stack, because this is faster than using malloc() for each call. The default threshold above which the stack is no longer used is 10; it can be changed by adding a setting such as 

  --with-posix-malloc-threshold=20

to the configure command.


LIMITING PCRE RESOURCE USAGE

Internally, PCRE has a function called match() which it calls repeatedly (possibly recursively) when performing a matching operation. By limiting the number of times this function may be called, a limit can be placed on the resources used by a single call to pcre_exec(). The limit can be changed at run time, as described in the pcreapi documentation. The default is 10 million, but this can be changed by adding a setting such as 

  --with-match-limit=500000

to the configure command.


HANDLING VERY LARGE PATTERNS

Within a compiled pattern, offset values are used to point from one part to another (for example, from an opening parenthesis to an alternation metacharacter). By default two-byte values are used for these offsets, leading to a maximum size for a compiled pattern of around 64K. This is sufficient to handle all but the most gigantic patterns. Nevertheless, some people do want to process enormous patterns, so it is possible to compile PCRE to use three-byte or four-byte offsets by adding a setting such as 

  --with-link-size=3

to the configure command. The value given must be 2, 3, or 4. Using longer offsets slows down the operation of PCRE because it has to load additional bytes when handling them.

If you build PCRE with an increased link size, test 2 (and test 5 if you are using UTF-8) will fail. Part of the output of these tests is a representation of the compiled pattern, and this changes with the link size.

Last updated: 21 January 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcrecallout.html0100644000000000000000000001071207721121074016540 0ustar rootroot pcrecallout specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


PCRE CALLOUTS

int (*pcre_callout)(pcre_callout_block *);

PCRE provides a feature called "callout", which is a means of temporarily passing control to the caller of PCRE in the middle of pattern matching. The caller of PCRE provides an external function by putting its entry point in the global variable pcre_callout. By default, this variable contains NULL, which disables all calling out.

Within a regular expression, (?C) indicates the points at which the external function is to be called. Different callout points can be identified by putting a number less than 256 after the letter C. The default value is zero. For example, this pattern has two callout points: 

  (?C1)\dabc(?C2)def

During matching, when PCRE reaches a callout point (and pcre_callout is set), the external function is called. Its only argument is a pointer to a pcre_callout block. This contains the following variables: 

  int          version;
  int          callout_number;
  int         *offset_vector;
  const char  *subject;
  int          subject_length;
  int          start_match;
  int          current_position;
  int          capture_top;
  int          capture_last;
  void        *callout_data;

The version field is an integer containing the version number of the block format. The current version is zero. The version number may change in future if additional fields are added, but the intention is never to remove any of the existing fields.

The callout_number field contains the number of the callout, as compiled into the pattern (that is, the number after ?C).

The offset_vector field is a pointer to the vector of offsets that was passed by the caller to pcre_exec(). The contents can be inspected in order to extract substrings that have been matched so far, in the same way as for extracting substrings after a match has completed.

The subject and subject_length fields contain copies the values that were passed to pcre_exec().

The start_match field contains the offset within the subject at which the current match attempt started. If the pattern is not anchored, the callout function may be called several times for different starting points.

The current_position field contains the offset within the subject of the current match pointer.

The capture_top field contains one more than the number of the highest numbered captured substring so far. If no substrings have been captured, the value of capture_top is one.

The capture_last field contains the number of the most recently captured substring.

The callout_data field contains a value that is passed to pcre_exec() by the caller specifically so that it can be passed back in callouts. It is passed in the pcre_callout field of the pcre_extra data structure. If no such data was passed, the value of callout_data in a pcre_callout block is NULL. There is a description of the pcre_extra structure in the pcreapi documentation.


RETURN VALUES

The callout function returns an integer. If the value is zero, matching proceeds as normal. If the value is greater than zero, matching fails at the current point, but backtracking to test other possibilities goes ahead, just as if a lookahead assertion had failed. If the value is less than zero, the match is abandoned, and pcre_exec() returns the value.

Negative values should normally be chosen from the set of PCRE_ERROR_xxx values. In particular, PCRE_ERROR_NOMATCH forces a standard "no match" failure. The error number PCRE_ERROR_CALLOUT is reserved for use by callout functions; it will never be used by PCRE itself.

Last updated: 21 January 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcrecompat.html0100644000000000000000000001114007721121074016354 0ustar rootroot pcrecompat specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


DIFFERENCES FROM PERL

This document describes the differences in the ways that PCRE and Perl handle regular expressions. The differences described here are with respect to Perl 5.8.

1. PCRE does not allow repeat quantifiers on lookahead assertions. Perl permits them, but they do not mean what you might think. For example, (?!a){3} does not assert that the next three characters are not "a". It just asserts that the next character is not "a" three times.

2. Capturing subpatterns that occur inside negative lookahead assertions are counted, but their entries in the offsets vector are never set. Perl sets its numerical variables from any such patterns that are matched before the assertion fails to match something (thereby succeeding), but only if the negative lookahead assertion contains just one branch.

3. Though binary zero characters are supported in the subject string, they are not allowed in a pattern string because it is passed as a normal C string, terminated by zero. The escape sequence "\0" can be used in the pattern to represent a binary zero.

4. The following Perl escape sequences are not supported: \l, \u, \L, \U, \P, \p, \N, and \X. 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.

5. PCRE does support the \Q...\E escape for quoting substrings. Characters in between are treated as literals. This is slightly different from Perl in that $ and @ are also handled as literals inside the quotes. In Perl, they cause variable interpolation (but of course PCRE does not have variables). Note the following examples: 

    Pattern            PCRE matches      Perl matches


    \Qabc$xyz\E        abc$xyz           abc followed by the
                                           contents of $xyz
    \Qabc\$xyz\E       abc\$xyz          abc\$xyz
    \Qabc\E\$\Qxyz\E   abc$xyz           abc$xyz

In PCRE, the \Q...\E mechanism is not recognized inside a character class.

8. Fairly obviously, PCRE does not support the (?{code}) and (?p{code}) constructions. However, there is some experimental support for recursive patterns using the non-Perl items (?R), (?number) and (?P>name). Also, the PCRE "callout" feature allows an external function to be called during pattern matching.

9. There are some differences that are concerned with the settings of captured strings when part of a pattern is repeated. For example, matching "aba" against the pattern /^(a(b)?)+$/ in Perl leaves $2 unset, but in PCRE it is set to "b".

10. PCRE provides some extensions to the Perl regular expression facilities:

(a) Although lookbehind assertions must match fixed length strings, each alternative branch of a lookbehind assertion can match a different length of string. Perl requires them all to have the same length.

(b) If PCRE_DOLLAR_ENDONLY is set and PCRE_MULTILINE is not set, the $ meta-character matches only at the very end of the string.

© If PCRE_EXTRA is set, a backslash followed by a letter with no special meaning is faulted.

(d) If PCRE_UNGREEDY is set, the greediness of the repetition quantifiers is inverted, that is, by default they are not greedy, but if followed by a question mark they are.

(e) PCRE_ANCHORED can be used to force a pattern to be tried only at the first matching position in the subject string.

(f) The PCRE_NOTBOL, PCRE_NOTEOL, PCRE_NOTEMPTY, and PCRE_NO_AUTO_CAPTURE options for pcre_exec() have no Perl equivalents.

(g) The (?R), (?number), and (?P>name) constructs allows for recursive pattern matching (Perl can do this using the (?p{code}) construct, which PCRE cannot support.)

(h) PCRE supports named capturing substrings, using the Python syntax.

(i) PCRE supports the possessive quantifier "++" syntax, taken from Sun's Java package.

(j) The (R) condition, for testing recursion, is a PCRE extension.

(k) The callout facility is PCRE-specific.

Last updated: 03 February 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcregrep.html0100644000000000000000000001156307721121074016037 0ustar rootroot pcregrep specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


SYNOPSIS

pcregrep [-Vcfhilnrsuvx] [long options] [pattern] [file1 file2 ...]


DESCRIPTION

pcregrep searches files for character patterns, in the same way as other grep commands do, but it uses the PCRE regular expression library to support patterns that are compatible with the regular expressions of Perl 5. See pcrepattern for a full description of syntax and semantics of the regular expressions that PCRE supports.

A pattern must be specified on the command line unless the -f option is used (see below).

If no files are specified, pcregrep reads the standard input. By default, each line that matches the pattern is copied to the standard output, and if there is more than one file, the file name is printed before each line of output. However, there are options that can change how pcregrep behaves.

Lines are limited to BUFSIZ characters. BUFSIZ is defined in <stdio.h>. The newline character is removed from the end of each line before it is matched against the pattern.


OPTIONS

-V Write the version number of the PCRE library being used to the standard error stream.

-c Do not print individual lines; instead just print a count of the number of lines that would otherwise have been printed. If several files are given, a count is printed for each of them.

-ffilename Read a number of patterns from the file, one per line, and match all of them against each line of input. A line is output if any of the patterns match it. When -f is used, no pattern is taken from the command line; all arguments are treated as file names. There is a maximum of 100 patterns. Trailing white space is removed, and blank lines are ignored. An empty file contains no patterns and therefore matches nothing.

-h Suppress printing of filenames when searching multiple files.

-i Ignore upper/lower case distinctions during comparisons.

-l Instead of printing lines from the files, just print the names of the files containing lines that would have been printed. Each file name is printed once, on a separate line.

-n Precede each line by its line number in the file.

-r If any file is a directory, recursively scan the files it contains. Without -r a directory is scanned as a normal file.

-s Work silently, that is, display nothing except error messages. The exit status indicates whether any matches were found.

-u Operate in UTF-8 mode. This option is available only if PCRE has been compiled with UTF-8 support. Both the pattern and each subject line are assumed to be valid strings of UTF-8 characters.

-v Invert the sense of the match, so that lines which do not match the pattern are now the ones that are found.

-x Force the pattern to be anchored (it must start matching at the beginning of the line) and in addition, require it to match the entire line. This is equivalent to having ^ and $ characters at the start and end of each alternative branch in the regular expression.


LONG OPTIONS

Long forms of all the options are available, as in GNU grep. They are shown in the following table: 

  -c   --count
  -h   --no-filename
  -i   --ignore-case
  -l   --files-with-matches
  -n   --line-number
  -r   --recursive
  -s   --no-messages
  -u   --utf-8
  -V   --version
  -v   --invert-match
  -x   --line-regex
  -x   --line-regexp

In addition, --file=filename is equivalent to -ffilename, and --help shows the list of options and then exits.


DIAGNOSTICS

Exit status is 0 if any matches were found, 1 if no matches were found, and 2 for syntax errors or inacessible files (even if matches were found).


AUTHOR

Philip Hazel <ph10@cam.ac.uk>
University Computing Service
Cambridge CB2 3QG, England.

Last updated: 03 February 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcrepattern.html0100644000000000000000000016563707721121074016573 0ustar rootroot pcrepattern specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


PCRE REGULAR EXPRESSION DETAILS

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 other books, some of which have copious examples. Jeffrey Friedl's "Mastering Regular Expressions", published by O'Reilly, covers them in great detail. The description here is intended as reference documentation.

The basic operation of PCRE is on strings of bytes. However, there is also support for UTF-8 character strings. To use this support you must build PCRE to include UTF-8 support, and then call pcre_compile() with the PCRE_UTF8 option. How this affects the pattern matching is mentioned in several places below. There is also a summary of UTF-8 features in the section on UTF-8 support in the main pcre page.

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 

  The quick brown fox

matches a portion of a subject string that is identical to itself. 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 meta-characters, which do not stand for themselves but instead are interpreted in some special way.

There are two different sets of meta-characters: those that are recognized anywhere in the pattern except within square brackets, and those that are recognized in square brackets. Outside square brackets, the meta-characters are as follows: 

  \      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

Part of a pattern that is in square brackets is called a "character class". In a character class the only meta-characters are: 

  \      general escape character
  ^      negate the class, but only if the first character
  -      indicates character range
  [      POSIX character class (only if followed by POSIX
           syntax)
  ]      terminates the character class

The following sections describe the use of each of the meta-characters.


BACKSLASH

The backslash character has several uses. Firstly, if it is followed by a non-alphameric 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.

For example, if you want to match a * character, you write \* in the pattern. This escaping action applies whether or not the following character would otherwise be interpreted as a meta-character, so it is always safe to precede a non-alphameric with backslash to specify that it stands for itself. In particular, if you want to match a backslash, you write \\.

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 character are ignored. An escaping backslash can be used to include a whitespace or # character as part of the pattern.

If you want to remove the special meaning from a sequence of characters, you can do so by putting them between \Q and \E. This is different from Perl in that $ and @ are handled as literals in \Q...\E sequences in PCRE, whereas in Perl, $ and @ cause variable interpolation. Note the following examples: 

  Pattern            PCRE matches   Perl matches


  \Qabc$xyz\E        abc$xyz        abc followed by the
                                      contents of $xyz
  \Qabc\$xyz\E       abc\$xyz       abc\$xyz
  \Qabc\E\$\Qxyz\E   abc$xyz        abc$xyz

The \Q...\E sequence is recognized both inside and outside character classes.

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: 

  \a        alarm, that is, the BEL character (hex 07)
  \cx       "control-x", where x is any character
  \e        escape (hex 1B)
  \f        formfeed (hex 0C)
  \n        newline (hex 0A)
  \r        carriage return (hex 0D)
  \t        tab (hex 09)
  \ddd      character with octal code ddd, or backreference
  \xhh      character with hex code hh
  \x{hhh..} character with hex code hhh... (UTF-8 mode only)

The precise effect of \cx 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 \cz becomes hex 1A, but \c{ becomes hex 3B, while \c; becomes hex 7B.

After \x, from zero to two hexadecimal digits are read (letters can be in upper or lower case). In UTF-8 mode, any number of hexadecimal digits may appear between \x{ and }, but the value of the character code must be less than 2**31 (that is, the maximum hexadecimal value is 7FFFFFFF). If characters other than hexadecimal digits appear between \x{ and }, or if there is no terminating }, this form of escape is not recognized. Instead, the initial \x will be interpreted as a basic hexadecimal escape, with no following digits, giving a byte whose value is zero.

Characters whose value is less than 256 can be defined by either of the two syntaxes for \x when PCRE is in UTF-8 mode. There is no difference in the way they are handled. For example, \xdc is exactly the same as \x{dc}.

After \0 up to two further octal digits are read. In both cases, if there are fewer than two digits, just those that are present are used. Thus the sequence \0\x\07 specifies two binary zeros followed by a BEL character (code value 7). Make sure you supply two digits after the initial zero if the character that follows is itself an octal digit.

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 back reference. A description of how this works is given later, following the discussion of parenthesized subpatterns.

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, and generates a single byte from the least significant 8 bits of the value. Any subsequent digits stand for themselves. For example: 

  \040   is another way of writing a space
  \40    is the same, provided there are fewer than 40
            previous capturing subpatterns
  \7     is always a back reference
  \11    might be a back reference, or another way of
            writing a tab
  \011   is always a tab
  \0113  is a tab followed by the character "3"
  \113   might be a back reference, otherwise the
            character with octal code 113
  \377   might be a back reference, otherwise
            the byte consisting entirely of 1 bits
  \81    is either a back reference, or a binary zero
            followed by the two characters "8" and "1"

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.

All the sequences that define a single byte value or a single UTF-8 character (in UTF-8 mode) can be used both inside and outside character classes. In addition, inside a character class, the sequence \b is interpreted as the backspace character (hex 08). Outside a character class it has a different meaning (see below).

The third use of backslash is for specifying generic character types: 

  \d     any decimal digit
  \D     any character that is not a decimal digit
  \s     any whitespace character
  \S     any character that is not a whitespace character
  \w     any "word" character
  \W     any "non-word" character

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.

In UTF-8 mode, characters with values greater than 255 never match \d, \s, or \w, and always match \D, \S, and \W.

For compatibility with Perl, \s does not match the VT character (code 11). This makes it different from the the POSIX "space" class. The \s characters are HT (9), LF (10), FF (12), CR (13), and space (32).

A "word" character is any letter or digit or the underscore character, that is, any character which can be part of a Perl "word". The definition of letters and digits is controlled by PCRE's character tables, and may vary if locale- specific matching is taking place (see "Locale support" in the pcreapi page). For example, in the "fr" (French) locale, some character codes greater than 128 are used for accented letters, and these are matched by \w.

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.

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 below. The backslashed assertions are 

  \b     matches at a word boundary
  \B     matches when not at a word boundary
  \A     matches at start of subject
  \Z     matches at end of subject or before newline at end
  \z     matches at end of subject
  \G     matches at first matching position in subject

These assertions may not appear in character classes (but note that \b has a different meaning, namely the backspace character, inside a character class).

A word boundary is a position in the subject string where the current character and the previous character do not both match \w or \W (i.e. one matches \w and the other matches \W), or the start or end of the string if the first or last character matches \w, respectively.

The \A, \Z, and \z assertions differ from the traditional circumflex and dollar (described below) 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.

They are not affected by the PCRE_NOTBOL or PCRE_NOTEOL options. If the startoffset argument of pcre_exec() is non-zero, indicating that matching is to start at a point other than the beginning of the subject, \A can never match. The difference between \Z and \z is that \Z matches before a newline that is the last character of the string as well as at the end of the string, whereas \z matches only at the end.

The \G assertion is true only when the current matching position is at the start point of the match, as specified by the startoffset argument of pcre_exec(). It differs from \A when the value of startoffset is non-zero. By calling pcre_exec() multiple times with appropriate arguments, you can mimic Perl's /g option, and it is in this kind of implementation where \G can be useful.

Note, however, that PCRE's interpretation of \G, 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.

If all the alternatives of a pattern begin with \G, the expression is anchored to the starting match position, and the "anchored" flag is set in the compiled regular expression.


CIRCUMFLEX AND DOLLAR

Outside a character class, in the default matching mode, the circumflex character is an assertion which is true only if the current matching point is at the start of the subject string. If the startoffset argument of pcre_exec() is non-zero, circumflex can never match if the PCRE_MULTILINE option is unset. Inside a character class, circumflex has an entirely different meaning (see below).

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.)

A dollar character is an assertion which is true only if the current matching point is at the end of the subject string, or immediately before a newline character that is the last character in 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.

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 \Z assertion.

The meanings of the circumflex and dollar characters are changed if the PCRE_MULTILINE option is set. When this is the case, they match immediately after and immediately before an internal newline character, respectively, in addition to matching at the start and end of the subject string. For example, the pattern /^abc$/ matches the subject string "def\nabc" 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 startoffset argument of pcre_exec() is non-zero. The PCRE_DOLLAR_ENDONLY option is ignored if PCRE_MULTILINE is set.

Note that the sequences \A, \Z, and \z can be used to match the start and end of the subject in both modes, and if all branches of a pattern start with \A it is always anchored, whether PCRE_MULTILINE is set or not.


FULL STOP (PERIOD, DOT)

Outside a character class, a dot in the pattern matches any one character in the subject, including a non-printing character, but not (by default) newline. In UTF-8 mode, a dot matches any UTF-8 character, which might be more than one byte long, except (by default) for newline. If the PCRE_DOTALL option is set, dots match newlines as well. The handling of dot is entirely independent of the handling of circumflex and dollar, the only relationship being that they both involve newline characters. Dot has no special meaning in a character class.


MATCHING A SINGLE BYTE

Outside a character class, the escape sequence \C matches any one byte, both in and out of UTF-8 mode. Unlike a dot, it always matches a newline. 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 it is best avoided.

PCRE does not allow \C to appear in lookbehind assertions (see below), because in UTF-8 mode it makes it impossible to calculate the length of the lookbehind.


SQUARE BRACKETS

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.

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.

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 which are in the class by enumerating those that are not. It is not an assertion: it still consumes a character from the subject string, and fails if the current pointer is at the end of the string.

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 \x{ escaping mechanism.

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. PCRE does not support the concept of case for characters with values greater than 255.

The newline character is never treated in any special way in character classes, whatever the setting of the PCRE_DOTALL or PCRE_MULTILINE options is. A class such as [^a] will always match a newline.

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.

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-\]46] is interpreted as a single class containing a range followed by two separate characters. The octal or hexadecimal representation of "]" can also be used to end a range.

Ranges operate in the collating sequence of character values. They can also be used for characters specified numerically, for example [\000-\037]. In UTF-8 mode, ranges can include characters whose values are greater than 255, for example [\x{100}-\x{2ff}].

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 [][\^_`wxyzabc], matched caselessly, and if character tables for the "fr" locale are in use, [\xc8-\xcb] matches accented E characters in both cases.

The character types \d, \D, \s, \S, \w, and \W may also appear in a character class, and add the characters that they match to the class. For example, [\dABCDEF] 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 [^\W_] matches any letter or digit, but not underscore.

All non-alphameric characters other than \, -, ^ (at the start) and the terminating ] are non-special in character classes, but it does no harm if they are escaped.


POSIX CHARACTER CLASSES

Perl supports the POSIX notation for character classes, which uses names enclosed by [: and :] within the enclosing square brackets. PCRE also supports this notation. For example, 

  [01[:alpha:]%]

matches "0", "1", any alphabetic character, or "%". The supported class names are 

  alnum    letters and digits
  alpha    letters
  ascii    character codes 0 - 127
  blank    space or tab only
  cntrl    control characters
  digit    decimal digits (same as \d)
  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 \s)
  upper    upper case letters
  word     "word" characters (same as \w)
  xdigit   hexadecimal digits

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 \s, which does not include VT (for Perl compatibility).

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, 

  [12[:^digit:]]

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.

In UTF-8 mode, characters with values greater than 255 do not match any of the POSIX character classes.


VERTICAL BAR

Vertical bar characters are used to separate alternative patterns. For example, the pattern 

  gilbert|sullivan

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 (defined below), "succeeds" means matching the rest of the main pattern as well as the alternative in the subpattern.


INTERNAL OPTION SETTING

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 

  i  for PCRE_CASELESS
  m  for PCRE_MULTILINE
  s  for PCRE_DOTALL
  x  for PCRE_EXTENDED

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.

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 pcre_fullinfo() function).

An option change within a subpattern affects only that part of the current pattern that follows it, so 

  (a(?i)b)c

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, 

  (a(?i)b|c)

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.

The PCRE-specific options PCRE_UNGREEDY and PCRE_EXTRA can be changed in the same way as the Perl-compatible options by using the characters U and X respectively. The (?X) flag setting is special in that it must always occur earlier in the pattern than any of the additional features it turns on, even when it is at top level. It is best put at the start.


SUBPATTERNS

Subpatterns are delimited by parentheses (round brackets), which can be nested. Marking part of a pattern as a subpattern does two things:

1. It localizes a set of alternatives. For example, the pattern 

  cat(aract|erpillar|)

matches one of the words "cat", "cataract", or "caterpillar". Without the parentheses, it would match "cataract", "erpillar" or the empty string.

2. It sets up the subpattern as a capturing subpattern (as defined above). When the whole pattern matches, that portion of the subject string that matched the subpattern is passed back to the caller via the ovector argument of pcre_exec(). Opening parentheses are counted from left to right (starting from 1) to obtain the numbers of the capturing subpatterns.

For example, if the string "the red king" is matched against the pattern 

  the ((red|white) (king|queen))

the captured substrings are "red king", "red", and "king", and are numbered 1, 2, and 3, respectively.

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 

  the ((?:red|white) (king|queen))

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.

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 

  (?i:saturday|sunday)
  (?:(?i)saturday|sunday)

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".


NAMED SUBPATTERNS

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 the difficulty, PCRE supports the naming of subpatterns, something that Perl does not provide. The Python syntax (?P<name>...) is used. Names consist of alphanumeric characters and underscores, and must be unique within a pattern.

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. For further details see the pcreapi documentation.


REPETITION

Repetition is specified by quantifiers, which can follow any of the following items: 

  a literal data character
  the . metacharacter
  the \C escape sequence
  escapes such as \d that match single characters
  a character class
  a back reference (see next section)
  a parenthesized subpattern (unless it is an assertion)

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: 

  z{2,4}

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 

  [aeiou]{3,}

matches at least 3 successive vowels, but may match many more, while 

  \d{8}

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.

In UTF-8 mode, quantifiers apply to UTF-8 characters rather than to individual bytes. Thus, for example, \x{100}{2} matches two UTF-8 characters, each of which is represented by a two-byte sequence.

The quantifier {0} is permitted, causing the expression to behave as if the previous item and the quantifier were not present.

For convenience (and historical compatibility) the three most common quantifiers have single-character abbreviations: 

  *    is equivalent to {0,}
  +    is equivalent to {1,}
  ?    is equivalent to {0,1}

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: 

  (a?)*

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.

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 the sequences /* and */ and within the sequence, individual * and / characters may appear. An attempt to match C comments by applying the pattern 

  /\*.*\*/

to the string 

  /* first command */  not comment  /* second comment */

fails, because it matches the entire string owing to the greediness of the .* item.

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 

  /\*.*?\*/

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 

  \d??\d

which matches one digit by preference, but can match two if that is the only way the rest of the pattern matches.

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.

When a parenthesized subpattern is quantified with a minimum repeat count that is greater than 1 or with a limited maximum, more store is required for the compiled pattern, in proportion to the size of the minimum or maximum.

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 \A.

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.

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: 

  (.*)abc\1

If the subject is "xyz123abc123" the match point is the fourth character. For this reason, such a pattern is not implicitly anchored.

When a capturing subpattern is repeated, the value captured is the substring that matched the final iteration. For example, after 

  (tweedle[dume]{3}\s*)+

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 

  /(a|(b))+/

matches "aba" the value of the second captured substring is "b".


ATOMIC GROUPING AND POSSESSIVE QUANTIFIERS

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.

Consider, for example, the pattern \d+foo when applied to the subject line 

  123456bar

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 \d+ 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.

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: 

  (?>\d+)bar

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.

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.

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 \d+ and \d+? are prepared to adjust the number of digits they match in order to make the rest of the pattern match, (?>\d+) can only match an entire sequence of digits.

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 

  \d++bar

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.

The possessive quantifier syntax is an extension to the Perl syntax. It originates in Sun's Java package.

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 

  (\D+|<\d+>)*[!?]

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 

  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

it takes a long time before reporting failure. This is because the string can be divided between the two repeats in a large number of ways, and all have to be tried. (The example used [!?] 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 to 

  ((?>\D+)|<\d+>)*[!?]

sequences of non-digits cannot be broken, and failure happens quickly.


BACK REFERENCES

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.

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. See the section entitled "Backslash" above for further details of the handling of digits following a backslash.

A back reference matches whatever actually matched the capturing subpattern in the current subject string, rather than anything matching the subpattern itself (see "Subpatterns as subroutines" below for a way of doing that). So the pattern 

  (sens|respons)e and \1ibility

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, 

  ((?i)rah)\s+\1

matches "rah rah" and "RAH RAH", but not "RAH rah", even though the original capturing subpattern is matched caselessly.

Back references to named subpatterns use the Python syntax (?P=name). We could rewrite the above example as follows: 

  (?<p1>(?i)rah)\s+(?P=p1)

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 

  (a|(bc))\2

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 can be used.

A back reference that occurs inside the parentheses to which it refers fails when the subpattern is first used, so, for example, (a\1) never matches. However, such references can be useful inside repeated subpatterns. For example, the pattern 

  (a|b\1)+

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.


ASSERTIONS

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 \b, \B, \A, \G, \Z, \z, ^ and $ are described above. 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. Lookahead assertions start with (?= for positive assertions and (?! for negative assertions. For example, 

  \w+(?=;)

matches a word followed by a semicolon, but does not include the semicolon in the match, and 

  foo(?!bar)

matches any occurrence of "foo" that is not followed by "bar". Note that the apparently similar pattern 

  (?!foo)bar

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 this effect.

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.

Lookbehind assertions start with (?<= for positive assertions and (?<! for negative assertions. For example, 

  (?<!foo)bar

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 alternatives, they do not all have to have the same fixed length. Thus 

  (?<=bullock|donkey)

is permitted, but 

  (?<!dogs?|cats?)

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 

  (?<=ab(c|de))

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: 

  (?<=abc|abde)

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.

PCRE does not allow the \C 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.

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 

  abcd$

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 

  ^.*abcd$

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 

  ^(?>.*)(?<=abcd)

or, equivalently, 

  ^.*+(?<=abcd)

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.

Several assertions (of any sort) may occur in succession. For example, 

  (?<=\d{3})(?<!999)foo

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 not 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 

  (?<=\d{3}...)(?<!999)foo

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".

Assertions can be nested in any combination. For example, 

  (?<=(?<!foo)bar)baz

matches an occurrence of "baz" that is preceded by "bar" which in turn is not preceded by "foo", while 

  (?<=\d{3}(?!999)...)foo

is another pattern which matches "foo" preceded by three digits and any three characters that are not "999".

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.


CONDITIONAL SUBPATTERNS

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 

  (?(condition)yes-pattern)
  (?(condition)yes-pattern|no-pattern)

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.

There are three kinds of condition. If the text between the parentheses consists of a sequence of digits, the condition is satisfied if the capturing subpattern of that number has previously matched. The number must be greater than zero. 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: 

  ( \( )?    [^()]+    (?(1) \) )

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.

If the condition is the string (R), it 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.

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: 

  (?(?=[^a-z]*[a-z])
  \d{2}-[a-z]{3}-\d{2}  |  \d{2}-\d{2}-\d{2} )

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.


COMMENTS

The sequence (?# marks the start of a comment which 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.

If the PCRE_EXTENDED option is set, an unescaped # character outside a character class introduces a comment that continues up to the next newline character in the pattern.


RECURSIVE PATTERNS

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 has provided an experimental 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: 

  $re = qr{\( (?: (?>[^()]+) | (?p{$re}) )* \)}x;

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.

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.

For example, this PCRE pattern solves the nested parentheses problem (assume the PCRE_EXTENDED option is set so that white space is ignored): 

  \( ( (?>[^()]+) | (?R) )* \)

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.

If this were part of a larger pattern, you would not want to recurse the entire pattern, so instead you could use this: 

  ( \( ( (?>[^()]+) | (?1) )* \) )

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: 

  (?<pn> \( ( (?>[^()]+) | (?P>pn) )* \) )

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 

  (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()

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.

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 below and the pcrecallout documentation). If the pattern above is matched against 

  (ab(cd)ef)

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 

  \( ( ( (?>[^()]+) | (?R) )* ) \)
     ^                        ^
     ^                        ^

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 pcre_malloc, freeing it via pcre_free afterwards. If no memory can be obtained, the match fails with the PCRE_ERROR_NOMEMORY error.

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. 

  < (?: (?(R) \d++  | [^<>]*+) | (?R)) * >

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.


SUBPATTERNS AS SUBROUTINES

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 

  (sens|respons)e and \1ibility

matches "sense and sensibility" and "response and responsibility", but not "sense and responsibility". If instead the pattern 

  (sens|respons)e and (?1)ibility

is used, it does match "sense and responsibility" as well as the other two strings. Such references must, however, follow the subpattern to which they refer.


CALLOUTS

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.

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 pcre_callout. By default, this variable contains NULL, which disables all calling out.

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: 

  (?C1)\dabc(?C2)def

During matching, when PCRE reaches a callout point (and pcre_callout is set), the external function is called. It is provided with the number of the callout, and, optionally, one item of data originally supplied by the caller of pcre_exec(). The callout function may cause matching to backtrack, or to fail altogether. A complete description of the interface to the callout function is given in the pcrecallout documentation.

Last updated: 03 February 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcreperform.html0100644000000000000000000000660307721121074016553 0ustar rootroot pcreperform specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


PCRE PERFORMANCE

Certain items that may appear in regular expression patterns are more efficient than others. It is more efficient to use a character class like [aeiou] than a set of alternatives such as (a|e|i|o|u). In general, the simplest construction that provides the required behaviour is usually the most efficient. Jeffrey Friedl's book contains a lot of discussion about optimizing regular expressions for efficient performance.

When a pattern begins with .* not in parentheses, or in parentheses that are not the subject of a backreference, and the PCRE_DOTALL option is set, the pattern is implicitly anchored by PCRE, since it can match only at the start of a subject string. However, if PCRE_DOTALL is not set, PCRE cannot make this optimization, because the . metacharacter does not then match a newline, and if the subject string contains newlines, the pattern may match from the character immediately following one of them instead of from the very start. For example, the pattern 

  .*second

matches the subject "first\nand second" (where \n stands for a newline character), with the match starting at the seventh character. In order to do this, PCRE has to retry the match starting after every newline in the subject.

If you are using such a pattern with subject strings that do not contain newlines, the best performance is obtained by setting PCRE_DOTALL, or starting the pattern with ^.* to indicate explicit anchoring. That saves PCRE from having to scan along the subject looking for a newline to restart at.

Beware of patterns that contain nested indefinite repeats. These can take a long time to run when applied to a string that does not match. Consider the pattern fragment 

  (a+)*

This can match "aaaa" in 33 different ways, and this number increases very rapidly as the string gets longer. (The * repeat can match 0, 1, 2, 3, or 4 times, and for each of those cases other than 0, the + repeats can match different numbers of times.) When the remainder of the pattern is such that the entire match is going to fail, PCRE has in principle to try every possible variation, and this can take an extremely long time.

An optimization catches some of the more simple cases such as 

  (a+)*b

where a literal character follows. Before embarking on the standard matching procedure, PCRE checks that there is a "b" later in the subject string, and if there is not, it fails the match immediately. However, when there is no following literal this optimization cannot be used. You can see the difference by comparing the behaviour of 

  (a+)*\d

with the pattern above. The former gives a failure almost instantly when applied to a whole line of "a" characters, whereas the latter takes an appreciable time with strings longer than about 20 characters.

Last updated: 03 February 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcreposix.html0100644000000000000000000002136107721121074016241 0ustar rootroot pcreposix specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


SYNOPSIS OF POSIX API

#include <pcreposix.h>

int regcomp(regex_t *preg, const char *pattern, int cflags);

int regexec(regex_t *preg, const char *string, size_t nmatch, regmatch_t pmatch[], int eflags);

size_t regerror(int errcode, const regex_t *preg, char *errbuf, size_t errbuf_size);

void regfree(regex_t *preg);


DESCRIPTION

This set of functions provides a POSIX-style API to the PCRE regular expression package. See the pcreapi documentation for a description of the native API, which contains additional functionality.

The functions described here are just wrapper functions that ultimately call the PCRE native API. Their prototypes are defined in the pcreposix.h header file, and on Unix systems the library itself is called pcreposix.a, so can be accessed by adding -lpcreposix to the command for linking an application which uses them. Because the POSIX functions call the native ones, it is also necessary to add \fR-lpcre\fR.

I have implemented only those option bits that can be reasonably mapped to PCRE native options. In addition, the options REG_EXTENDED and REG_NOSUB are defined with the value zero. They have no effect, but since programs that are written to the POSIX interface often use them, this makes it easier to slot in PCRE as a replacement library. Other POSIX options are not even defined.

When PCRE is called via these functions, it is only the API that is POSIX-like in style. The syntax and semantics of the regular expressions themselves are still those of Perl, subject to the setting of various PCRE options, as described below. "POSIX-like in style" means that the API approximates to the POSIX definition; it is not fully POSIX-compatible, and in multi-byte encoding domains it is probably even less compatible.

The header for these functions is supplied as pcreposix.h to avoid any potential clash with other POSIX libraries. It can, of course, be renamed or aliased as regex.h, which is the "correct" name. It provides two structure types, regex_t for compiled internal forms, and regmatch_t for returning captured substrings. It also defines some constants whose names start with "REG_"; these are used for setting options and identifying error codes.


COMPILING A PATTERN

The function regcomp() is called to compile a pattern into an internal form. The pattern is a C string terminated by a binary zero, and is passed in the argument pattern. The preg argument is a pointer to a regex_t structure which is used as a base for storing information about the compiled expression.

The argument cflags is either zero, or contains one or more of the bits defined by the following macros: 

  REG_ICASE

The PCRE_CASELESS option is set when the expression is passed for compilation to the native function. 

  REG_NEWLINE

The PCRE_MULTILINE option is set when the expression is passed for compilation to the native function. Note that this does not mimic the defined POSIX behaviour for REG_NEWLINE (see the following section).

In the absence of these flags, no options are passed to the native function. This means the the regex is compiled with PCRE default semantics. In particular, the way it handles newline characters in the subject string is the Perl way, not the POSIX way. Note that setting PCRE_MULTILINE has only some of the effects specified for REG_NEWLINE. It does not affect the way newlines are matched by . (they aren't) or by a negative class such as [^a] (they are).

The yield of regcomp() is zero on success, and non-zero otherwise. The preg structure is filled in on success, and one member of the structure is public: re_nsub contains the number of capturing subpatterns in the regular expression. Various error codes are defined in the header file.


MATCHING NEWLINE CHARACTERS

This area is not simple, because POSIX and Perl take different views of things. It is not possible to get PCRE to obey POSIX semantics, but then PCRE was never intended to be a POSIX engine. The following table lists the different possibilities for matching newline characters in PCRE: 

                          Default   Change with


  . matches newline          no     PCRE_DOTALL
  newline matches [^a]       yes    not changeable
  $ matches \n at end        yes    PCRE_DOLLARENDONLY
  $ matches \n in middle     no     PCRE_MULTILINE
  ^ matches \n in middle     no     PCRE_MULTILINE

This is the equivalent table for POSIX: 

                          Default   Change with


  . matches newline          yes      REG_NEWLINE
  newline matches [^a]       yes      REG_NEWLINE
  $ matches \n at end        no       REG_NEWLINE
  $ matches \n in middle     no       REG_NEWLINE
  ^ matches \n in middle     no       REG_NEWLINE

PCRE's behaviour is the same as Perl's, except that there is no equivalent for PCRE_DOLLARENDONLY in Perl. In both PCRE and Perl, there is no way to stop newline from matching [^a].

The default POSIX newline handling can be obtained by setting PCRE_DOTALL and PCRE_DOLLARENDONLY, but there is no way to make PCRE behave exactly as for the REG_NEWLINE action.


MATCHING A PATTERN

The function regexec() is called to match a pre-compiled pattern preg against a given string, which is terminated by a zero byte, subject to the options in eflags. These can be: 

  REG_NOTBOL

The PCRE_NOTBOL option is set when calling the underlying PCRE matching function. 

  REG_NOTEOL

The PCRE_NOTEOL option is set when calling the underlying PCRE matching function.

The portion of the string that was matched, and also any captured substrings, are returned via the pmatch argument, which points to an array of nmatch structures of type regmatch_t, containing the members rm_so and rm_eo. These contain the offset to the first character of each substring and the offset to the first character after the end of each substring, respectively. The 0th element of the vector relates to the entire portion of string that was matched; subsequent elements relate to the capturing subpatterns of the regular expression. Unused entries in the array have both structure members set to -1.

A successful match yields a zero return; various error codes are defined in the header file, of which REG_NOMATCH is the "expected" failure code.


ERROR MESSAGES

The regerror() function maps a non-zero errorcode from either regcomp() or regexec() to a printable message. If preg is not NULL, the error should have arisen from the use of that structure. A message terminated by a binary zero is placed in errbuf. The length of the message, including the zero, is limited to errbuf_size. The yield of the function is the size of buffer needed to hold the whole message.


STORAGE

Compiling a regular expression causes memory to be allocated and associated with the preg structure. The function regfree() frees all such memory, after which preg may no longer be used as a compiled expression.


AUTHOR

Philip Hazel <ph10@cam.ac.uk>
University Computing Service,
Cambridge CB2 3QG, England.

Last updated: 03 February 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcresample.html0100644000000000000000000000460607721121074016363 0ustar rootroot pcresample specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


PCRE SAMPLE PROGRAM

A simple, complete demonstration program, to get you started with using PCRE, is supplied in the file pcredemo.c in the PCRE distribution.

The program compiles the regular expression that is its first argument, and matches it against the subject string in its second argument. No PCRE options are set, and default character tables are used. If matching succeeds, the program outputs the portion of the subject that matched, together with the contents of any captured substrings.

If the -g option is given on the command line, the program then goes on to check for further matches of the same regular expression in the same subject string. The logic is a little bit tricky because of the possibility of matching an empty string. Comments in the code explain what is going on.

On a Unix system that has PCRE installed in /usr/local, you can compile the demonstration program using a command like this: 

  gcc -o pcredemo pcredemo.c -I/usr/local/include \
      -L/usr/local/lib -lpcre

Then you can run simple tests like this: 

  ./pcredemo 'cat|dog' 'the cat sat on the mat'
  ./pcredemo -g 'cat|dog' 'the dog sat on the cat'

Note that there is a much more comprehensive test program, called pcretest, which supports many more facilities for testing regular expressions and the PCRE library. The pcredemo program is provided as a simple coding example.

On some operating systems (e.g. Solaris) you may get an error like this when you try to run pcredemo: 

  ld.so.1: a.out: fatal: libpcre.so.0: open failed: No such file or directory

This is caused by the way shared library support works on those systems. You need to add 

  -R/usr/local/lib

to the compile command to get round this problem.

Last updated: 28 January 2003
Copyright © 1997-2003 University of Cambridge. usr/doc/pcre-4.4/html/pcretest.html0100644000000000000000000004043707721121074016063 0ustar rootroot pcretest specification This HTML document has been generated automatically from the original man page. If there is any nonsense in it, please consult the man page, in case the conversion went wrong.


SYNOPSIS

pcretest [-d] [-i] [-m] [-o osize] [-p] [-t] [source] [destination]

pcretest was written as a test program for the PCRE regular expression library itself, but it can also be used for experimenting with regular expressions. This document describes the features of the test program; for details of the regular expressions themselves, see the pcrepattern documentation. For details of PCRE and its options, see the pcreapi documentation.


OPTIONS

-C Output the version number of the PCRE library, and all available information about the optional features that are included, and then exit.

-d Behave as if each regex had the /D modifier (see below); the internal form is output after compilation.

-i Behave as if each regex had the /I modifier; information about the compiled pattern is given after compilation.

-m Output the size of each compiled pattern after it has been compiled. This is equivalent to adding /M to each regular expression. For compatibility with earlier versions of pcretest, -s is a synonym for -m.

-o osize Set the number of elements in the output vector that is used when calling PCRE to be osize. The default value is 45, which is enough for 14 capturing subexpressions. The vector size can be changed for individual matching calls by including \O in the data line (see below).

-p Behave as if each regex has /P modifier; the POSIX wrapper API is used to call PCRE. None of the other options has any effect when -p is set.

-t Run each compile, study, and match many times with a timer, and output resulting time per compile or match (in milliseconds). Do not set -t with -m, because you will then get the size output 20000 times and the timing will be distorted.


DESCRIPTION

If pcretest is given two filename arguments, it reads from the first and writes to the second. If it is given only one filename argument, it reads from that file and writes to stdout. Otherwise, it reads from stdin and writes to stdout, and prompts for each line of input, using "re>" to prompt for regular expressions, and "data>" to prompt for data lines.

The program handles any number of sets of input on a single input file. Each set starts with a regular expression, and continues with any number of data lines to be matched against the pattern.

Each line is matched separately and independently. If you want to do multiple-line matches, you have to use the \n escape sequence in a single line of input to encode the newline characters. The maximum length of data line is 30,000 characters.

An empty line signals the end of the data lines, at which point a new regular expression is read. The regular expressions are given enclosed in any non-alphameric delimiters other than backslash, for example 

  /(a|bc)x+yz/

White space before the initial delimiter is ignored. A regular expression may be continued over several input lines, in which case the newline characters are included within it. It is possible to include the delimiter within the pattern by escaping it, for example 

  /abc\/def/

If you do so, the escape and the delimiter form part of the pattern, but since delimiters are always non-alphameric, this does not affect its interpretation. If the terminating delimiter is immediately followed by a backslash, for example, 

  /abc/\

then a backslash is added to the end of the pattern. This is done to provide a way of testing the error condition that arises if a pattern finishes with a backslash, because 

  /abc\/

is interpreted as the first line of a pattern that starts with "abc/", causing pcretest to read the next line as a continuation of the regular expression.


PATTERN MODIFIERS

The pattern may be followed by i, m, s, or x to set the PCRE_CASELESS, PCRE_MULTILINE, PCRE_DOTALL, or PCRE_EXTENDED options, respectively. For example: 

  /caseless/i

These modifier letters have the same effect as they do in Perl. There are others that set PCRE options that do not correspond to anything in Perl: /A, /E, /N, /U, and /X set PCRE_ANCHORED, PCRE_DOLLAR_ENDONLY, PCRE_NO_AUTO_CAPTURE, PCRE_UNGREEDY, and PCRE_EXTRA respectively.

Searching for all possible matches within each subject string can be requested by the /g or /G modifier. After finding a match, PCRE is called again to search the remainder of the subject string. The difference between /g and /G is that the former uses the startoffset argument to pcre_exec() to start searching at a new point within the entire string (which is in effect what Perl does), whereas the latter passes over a shortened substring. This makes a difference to the matching process if the pattern begins with a lookbehind assertion (including \b or \B).

If any call to pcre_exec() in a /g or /G sequence matches an empty string, the next call is done with the PCRE_NOTEMPTY and PCRE_ANCHORED flags set in order to search for another, non-empty, match at the same point. If this second match fails, the start offset is advanced by one, and the normal match is retried. This imitates the way Perl handles such cases when using the /g modifier or the split() function.

There are a number of other modifiers for controlling the way pcretest operates.

The /+ modifier requests that as well as outputting the substring that matched the entire pattern, pcretest should in addition output the remainder of the subject string. This is useful for tests where the subject contains multiple copies of the same substring.

The /L modifier must be followed directly by the name of a locale, for example, 

  /pattern/Lfr

For this reason, it must be the last modifier letter. The given locale is set, pcre_maketables() is called to build a set of character tables for the locale, and this is then passed to pcre_compile() when compiling the regular expression. Without an /L modifier, NULL is passed as the tables pointer; that is, /L applies only to the expression on which it appears.

The /I modifier requests that pcretest output information about the compiled expression (whether it is anchored, has a fixed first character, and so on). It does this by calling pcre_fullinfo() after compiling an expression, and outputting the information it gets back. If the pattern is studied, the results of that are also output.

The /D modifier is a PCRE debugging feature, which also assumes /I. It causes the internal form of compiled regular expressions to be output after compilation. If the pattern was studied, the information returned is also output.

The /S modifier causes pcre_study() to be called after the expression has been compiled, and the results used when the expression is matched.

The /M modifier causes the size of memory block used to hold the compiled pattern to be output.

The /P modifier causes pcretest to call PCRE via the POSIX wrapper API rather than its native API. When this is done, all other modifiers except /i, /m, and /+ are ignored. REG_ICASE is set if /i is present, and REG_NEWLINE is set if /m is present. The wrapper functions force PCRE_DOLLAR_ENDONLY always, and PCRE_DOTALL unless REG_NEWLINE is set.

The /8 modifier causes pcretest to call PCRE with the PCRE_UTF8 option set. This turns on support for UTF-8 character handling in PCRE, provided that it was compiled with this support enabled. This modifier also causes any non-printing characters in output strings to be printed using the \x{hh...} notation if they are valid UTF-8 sequences.

If the /? modifier is used with /8, it causes pcretest to call pcre_compile() with the PCRE_NO_UTF8_CHECK option, to suppress the checking of the string for UTF-8 validity.


CALLOUTS

If the pattern contains any callout requests, pcretest's callout function will be called. By default, it displays the callout number, and the start and current positions in the text at the callout time. For example, the output 

  --->pqrabcdef
    0    ^  ^

indicates that callout number 0 occurred for a match attempt starting at the fourth character of the subject string, when the pointer was at the seventh character. The callout function returns zero (carry on matching) by default.

Inserting callouts may be helpful when using pcretest to check complicated regular expressions. For further information about callouts, see the pcrecallout documentation.

For testing the PCRE library, additional control of callout behaviour is available via escape sequences in the data, as described in the following section. In particular, it is possible to pass in a number as callout data (the default is zero). If the callout function receives a non-zero number, it returns that value instead of zero.


DATA LINES

Before each data line is passed to pcre_exec(), leading and trailing whitespace is removed, and it is then scanned for \ escapes. Some of these are pretty esoteric features, intended for checking out some of the more complicated features of PCRE. If you are just testing "ordinary" regular expressions, you probably don't need any of these. The following escapes are recognized: 

  \a         alarm (= BEL)
  \b         backspace
  \e         escape
  \f         formfeed
  \n         newline
  \r         carriage return
  \t         tab
  \v         vertical tab
  \nnn       octal character (up to 3 octal digits)
  \xhh       hexadecimal character (up to 2 hex digits)
  \x{hh...}  hexadecimal character, any number of digits
               in UTF-8 mode
  \A         pass the PCRE_ANCHORED option to pcre_exec()
  \B         pass the PCRE_NOTBOL option to pcre_exec()
  \Cdd       call pcre_copy_substring() for substring dd
               after a successful match (any decimal number
               less than 32)
  \Cname     call pcre_copy_named_substring() for substring
               "name" after a successful match (name termin-
               ated by next non alphanumeric character)
  \C+        show the current captured substrings at callout
               time
  \C-        do not supply a callout function
  \C!n       return 1 instead of 0 when callout number n is
               reached
  \C!n!m     return 1 instead of 0 when callout number n is
               reached for the nth time
  \C*n       pass the number n (may be negative) as callout
               data
  \Gdd       call pcre_get_substring() for substring dd
               after a successful match (any decimal number
               less than 32)
  \Gname     call pcre_get_named_substring() for substring
               "name" after a successful match (name termin-
               ated by next non-alphanumeric character)
  \L         call pcre_get_substringlist() after a
               successful match
  \M         discover the minimum MATCH_LIMIT setting
  \N         pass the PCRE_NOTEMPTY option to pcre_exec()
  \Odd       set the size of the output vector passed to
               pcre_exec() to dd (any number of decimal
               digits)
  \Z         pass the PCRE_NOTEOL option to pcre_exec()
  \?         pass the PCRE_NO_UTF8_CHECK option to
               pcre_exec()

If \M is present, pcretest calls pcre_exec() several times, with different values in the match_limit field of the pcre_extra data structure, until it finds the minimum number that is needed for pcre_exec() to complete. This number is a measure of the amount of recursion and backtracking that takes place, and checking it out can be instructive. For most simple matches, the number is quite small, but for patterns with very large numbers of matching possibilities, it can become large very quickly with increasing length of subject string.

When \O is used, it may be higher or lower than the size set by the -O option (or defaulted to 45); \O applies only to the call of pcre_exec() for the line in which it appears.

A backslash followed by anything else just escapes the anything else. If the very last character is a backslash, it is ignored. This gives a way of passing an empty line as data, since a real empty line terminates the data input.

If /P was present on the regex, causing the POSIX wrapper API to be used, only \B, and \Z have any effect, causing REG_NOTBOL and REG_NOTEOL to be passed to regexec() respectively.

The use of \x{hh...} to represent UTF-8 characters is not dependent on the use of the /8 modifier on the pattern. It is recognized always. There may be any number of hexadecimal digits inside the braces. The result is from one to six bytes, encoded according to the UTF-8 rules.


OUTPUT FROM PCRETEST

When a match succeeds, pcretest outputs the list of captured substrings that pcre_exec() returns, starting with number 0 for the string that matched the whole pattern. Here is an example of an interactive pcretest run. 

  $ pcretest
  PCRE version 4.00 08-Jan-2003


    re> /^abc(\d+)/
  data> abc123
   0: abc123
   1: 123
  data> xyz
  No match

If the strings contain any non-printing characters, they are output as \0x escapes, or as \x{...} escapes if the /8 modifier was present on the pattern. If the pattern has the /+ modifier, then the output for substring 0 is followed by the the rest of the subject string, identified by "0+" like this: 

    re> /cat/+
  data> cataract
   0: cat
   0+ aract

If the pattern has the /g or /G modifier, the results of successive matching attempts are output in sequence, like this: 

    re> /\Bi(\w\w)/g
  data> Mississippi
   0: iss
   1: ss
   0: iss
   1: ss
   0: ipp
   1: pp

"No match" is output only if the first match attempt fails.

If any of the sequences \C, \G, or \L are present in a data line that is successfully matched, the substrings extracted by the convenience functions are output with C, G, or L after the string number instead of a colon. This is in addition to the normal full list. The string length (that is, the return from the extraction function) is given in parentheses after each string for \C and \G.

Note that while patterns can be continued over several lines (a plain ">" prompt is used for continuations), data lines may not. However newlines can be included in data by means of the \n escape.


AUTHOR

Philip Hazel <ph10@cam.ac.uk>
University Computing Service,
Cambridge CB2 3QG, England.

Last updated: 20 August 2003
Copyright © 1997-2003 University of Cambridge. usr/include/0040755000000000000000000000000007776057301012030 5ustar rootrootusr/include/pcre.h0100644000000000000000000001505207776057166013143 0ustar rootroot/************************************************* * Perl-Compatible Regular Expressions * *************************************************/ /* Copyright (c) 1997-2003 University of Cambridge */ #ifndef _PCRE_H #define _PCRE_H /* The file pcre.h is build by "configure". Do not edit it; instead make changes to pcre.in. */ #define PCRE_MAJOR 4 #define PCRE_MINOR 4 #define PCRE_DATE 21-August-2003 /* Win32 uses DLL by default */ #ifdef _WIN32 # ifdef PCRE_DEFINITION # ifdef DLL_EXPORT # define PCRE_DATA_SCOPE __declspec(dllexport) # endif # else # ifndef PCRE_STATIC # define PCRE_DATA_SCOPE extern __declspec(dllimport) # endif # endif #endif #ifndef PCRE_DATA_SCOPE # define PCRE_DATA_SCOPE extern #endif /* Have to include stdlib.h in order to ensure that size_t is defined; it is needed here for malloc. */ #include /* Allow for C++ users */ #ifdef __cplusplus extern "C" { #endif /* Options */ #define PCRE_CASELESS 0x0001 #define PCRE_MULTILINE 0x0002 #define PCRE_DOTALL 0x0004 #define PCRE_EXTENDED 0x0008 #define PCRE_ANCHORED 0x0010 #define PCRE_DOLLAR_ENDONLY 0x0020 #define PCRE_EXTRA 0x0040 #define PCRE_NOTBOL 0x0080 #define PCRE_NOTEOL 0x0100 #define PCRE_UNGREEDY 0x0200 #define PCRE_NOTEMPTY 0x0400 #define PCRE_UTF8 0x0800 #define PCRE_NO_AUTO_CAPTURE 0x1000 #define PCRE_NO_UTF8_CHECK 0x2000 /* Exec-time and get/set-time error codes */ #define PCRE_ERROR_NOMATCH (-1) #define PCRE_ERROR_NULL (-2) #define PCRE_ERROR_BADOPTION (-3) #define PCRE_ERROR_BADMAGIC (-4) #define PCRE_ERROR_UNKNOWN_NODE (-5) #define PCRE_ERROR_NOMEMORY (-6) #define PCRE_ERROR_NOSUBSTRING (-7) #define PCRE_ERROR_MATCHLIMIT (-8) #define PCRE_ERROR_CALLOUT (-9) /* Never used by PCRE itself */ #define PCRE_ERROR_BADUTF8 (-10) /* Request types for pcre_fullinfo() */ #define PCRE_INFO_OPTIONS 0 #define PCRE_INFO_SIZE 1 #define PCRE_INFO_CAPTURECOUNT 2 #define PCRE_INFO_BACKREFMAX 3 #define PCRE_INFO_FIRSTBYTE 4 #define PCRE_INFO_FIRSTCHAR 4 /* For backwards compatibility */ #define PCRE_INFO_FIRSTTABLE 5 #define PCRE_INFO_LASTLITERAL 6 #define PCRE_INFO_NAMEENTRYSIZE 7 #define PCRE_INFO_NAMECOUNT 8 #define PCRE_INFO_NAMETABLE 9 #define PCRE_INFO_STUDYSIZE 10 /* Request types for pcre_config() */ #define PCRE_CONFIG_UTF8 0 #define PCRE_CONFIG_NEWLINE 1 #define PCRE_CONFIG_LINK_SIZE 2 #define PCRE_CONFIG_POSIX_MALLOC_THRESHOLD 3 #define PCRE_CONFIG_MATCH_LIMIT 4 /* Bit flags for the pcre_extra structure */ #define PCRE_EXTRA_STUDY_DATA 0x0001 #define PCRE_EXTRA_MATCH_LIMIT 0x0002 #define PCRE_EXTRA_CALLOUT_DATA 0x0004 /* Types */ struct real_pcre; /* declaration; the definition is private */ typedef struct real_pcre pcre; /* The structure for passing additional data to pcre_exec(). This is defined in such as way as to be extensible. */ typedef struct pcre_extra { unsigned long int flags; /* Bits for which fields are set */ void *study_data; /* Opaque data from pcre_study() */ unsigned long int match_limit; /* Maximum number of calls to match() */ void *callout_data; /* Data passed back in callouts */ } pcre_extra; /* The structure for passing out data via the pcre_callout_function. We use a structure so that new fields can be added on the end in future versions, without changing the API of the function, thereby allowing old clients to work without modification. */ typedef struct pcre_callout_block { int version; /* Identifies version of block */ /* ------------------------ Version 0 ------------------------------- */ int callout_number; /* Number compiled into pattern */ int *offset_vector; /* The offset vector */ const char *subject; /* The subject being matched */ int subject_length; /* The length of the subject */ int start_match; /* Offset to start of this match attempt */ int current_position; /* Where we currently are */ int capture_top; /* Max current capture */ int capture_last; /* Most recently closed capture */ void *callout_data; /* Data passed in with the call */ /* ------------------------------------------------------------------ */ } pcre_callout_block; /* Indirection for store get and free functions. These can be set to alternative malloc/free functions if required. There is also an optional callout function that is triggered by the (?) regex item. Some magic is required for Win32 DLL; it is null on other OS. For Virtual Pascal, these have to be different again. */ #ifndef VPCOMPAT PCRE_DATA_SCOPE void *(*pcre_malloc)(size_t); PCRE_DATA_SCOPE void (*pcre_free)(void *); PCRE_DATA_SCOPE int (*pcre_callout)(pcre_callout_block *); #else /* VPCOMPAT */ extern void *pcre_malloc(size_t); extern void pcre_free(void *); extern int pcre_callout(pcre_callout_block *); #endif /* VPCOMPAT */ /* Exported PCRE functions */ extern pcre *pcre_compile(const char *, int, const char **, int *, const unsigned char *); extern int pcre_config(int, void *); extern int pcre_copy_named_substring(const pcre *, const char *, int *, int, const char *, char *, int); extern int pcre_copy_substring(const char *, int *, int, int, char *, int); extern int pcre_exec(const pcre *, const pcre_extra *, const char *, int, int, int, int *, int); extern void pcre_free_substring(const char *); extern void pcre_free_substring_list(const char **); extern int pcre_fullinfo(const pcre *, const pcre_extra *, int, void *); extern int pcre_get_named_substring(const pcre *, const char *, int *, int, const char *, const char **); extern int pcre_get_stringnumber(const pcre *, const char *); extern int pcre_get_substring(const char *, int *, int, int, const char **); extern int pcre_get_substring_list(const char *, int *, int, const char ***); extern int pcre_info(const pcre *, int *, int *); extern const unsigned char *pcre_maketables(void); extern pcre_extra *pcre_study(const pcre *, int, const char **); extern const char *pcre_version(void); #ifdef __cplusplus } /* extern "C" */ #endif #endif /* End of pcre.h */ usr/include/pcreposix.h0100644000000000000000000000445307776057166014231 0ustar rootroot/************************************************* * Perl-Compatible Regular Expressions * *************************************************/ /* Copyright (c) 1997-2003 University of Cambridge */ #ifndef _PCREPOSIX_H #define _PCREPOSIX_H /* This is the header for the POSIX wrapper interface to the PCRE Perl- Compatible Regular Expression library. It defines the things POSIX says should be there. I hope. */ /* Have to include stdlib.h in order to ensure that size_t is defined. */ #include /* Allow for C++ users */ #ifdef __cplusplus extern "C" { #endif /* Options defined by POSIX. */ #define REG_ICASE 0x01 #define REG_NEWLINE 0x02 #define REG_NOTBOL 0x04 #define REG_NOTEOL 0x08 /* These are not used by PCRE, but by defining them we make it easier to slot PCRE into existing programs that make POSIX calls. */ #define REG_EXTENDED 0 #define REG_NOSUB 0 /* Error values. Not all these are relevant or used by the wrapper. */ enum { REG_ASSERT = 1, /* internal error ? */ REG_BADBR, /* invalid repeat counts in {} */ REG_BADPAT, /* pattern error */ REG_BADRPT, /* ? * + invalid */ REG_EBRACE, /* unbalanced {} */ REG_EBRACK, /* unbalanced [] */ REG_ECOLLATE, /* collation error - not relevant */ REG_ECTYPE, /* bad class */ REG_EESCAPE, /* bad escape sequence */ REG_EMPTY, /* empty expression */ REG_EPAREN, /* unbalanced () */ REG_ERANGE, /* bad range inside [] */ REG_ESIZE, /* expression too big */ REG_ESPACE, /* failed to get memory */ REG_ESUBREG, /* bad back reference */ REG_INVARG, /* bad argument */ REG_NOMATCH /* match failed */ }; /* The structure representing a compiled regular expression. */ typedef struct { void *re_pcre; size_t re_nsub; size_t re_erroffset; } regex_t; /* The structure in which a captured offset is returned. */ typedef int regoff_t; typedef struct { regoff_t rm_so; regoff_t rm_eo; } regmatch_t; /* The functions */ extern int regcomp(regex_t *, const char *, int); extern int regexec(const regex_t *, const char *, size_t, regmatch_t *, int); extern size_t regerror(int, const regex_t *, char *, size_t); extern void regfree(regex_t *); #ifdef __cplusplus } /* extern "C" */ #endif #endif /* End of pcreposix.h */ usr/lib/0040755000000000000000000000000007776057322011156 5ustar rootrootusr/lib/libpcre.a0100644000000000000000000016727007776057311012750 0ustar rootroot! / 1073241801 0 0 0 396 `  '''''''''pcre_maketablespcre_get_stringnumberpcre_copy_substringpcre_copy_named_substringpcre_get_substring_listpcre_free_substring_listpcre_get_substringpcre_get_named_substringpcre_free_substringpcre_studypcre_mallocpcre_freepcre_calloutpcre_versionpcre_infopcre_fullinfopcre_configpcre_compilepcre_execmaketables.o/ 1073241678 0 0 100644 2244 ` ELF44( oX(@X0P "P `(X`XʧU$ ;0X XBXX` PdX` XpX ʧK;A!  U$ ;0X XCBXd? rˉXpA, +Dv I@C2@C4BB2@ X A\P+DS I@C2`C4BB2` X A, +D0 I@C2C4BB2_ X A\ PKD@(+90 CB X A, KD@(+90 C B X A\PKDɊ@(+90 CB X A,@ KD@(+90 CB X A\PKD@(+90 CB X AKDo@(+90 C B @X`Xp  ˉX A\ P X Ht_&; "BX `X@oJJsJUJ7JJ*Ч**U$ ;0X X3P*+?{^.$|()[ | `(PD jGCC: (GNU) 3.3.symtab.strtab.shstrtab.rela.text.data.bss.rodata.str1.2.rela.eh_frame.comment 4PpH  &,12 E<@  OX  lP#/CQemaketables.c.LC4pcre_maketablespcre_malloc__ctype_tolower_loc__ctype_b_loc__ctype_toupper_locstrchr    get.o/ 1073241679 0 0 100644 2744 ` ELF4( oXH8AP`P "t`HAPd+8H "X@o+APh8H "tX`%X`dXphRX;:( "" $(P`(C  C!lU§DTDH$lHX0X100#*X`D3SZ, F @ A@AA !@ DPB`CǐoX6P "<)JPX`ȧ X`  X@ooPbuH:0+ X[AJ6X$X0 "§(KH@LJPp8 + XX2V!S 4 0PA01APQ&%0PD P@J@JϧP(X@ox4XX0P X@oUPDTD (X@oxXX0[0X0,* "2(X*\Z)C @ A@AA !@ DPB0,P0`oX6P "<)JPX`X  X@ox4XX0P X@ | `(D R@D (`VD R(D N*D R(D N(PD R,*D RGCC: (GNU) 3.3.symtab.strtab.shstrtab.rela.text.data.bss.rela.eh_frame.comment 4< x  &p,p6pD1 X`  @I0  +2FV`x*P*get.cpcre_get_stringnumberpcre_fullinfostrcmppcre_copy_substringpcre_copy_named_substringpcre_get_substring_listpcre_mallocpcre_free_substring_listpcre_freepcre_get_substringpcre_get_named_substringpcre_free_substring    Dd0study.o/ 1073241680 0 0 100644 4584 ` ELF 4( (3CD0@:0C$#B$XP JA! XP8C!20T @ CB(JoKFPPPdxCU$RAN!*U $ XX"(X@oHX X0C$C@@8!B$JVC(C =(էHX XC$C1@@#B$JVۧHX X0C$C@8!B$JVŧHX XC$C1@#B$JVHX X0C$C@8!B$JVHX XC$C1@#B$JVCwtJ}X8,C0HZ oX8,C0HZ X8,C0HZ ᧺է֧ͧ(C *U $ XX"HX X0C$C@@8!B$JVHX XC$C1@@#B$JVHX X0C$C@8!B$JV{HX XC$C1@#B$JVhHX X0C$C@8!B$JVRHX XC$C1@#B$JV?r9XdyH8CC$BJ6HDD`C!!&(X$ V 1D@0T$% T@ CBJ?JŅ (C *U $$ X X"xԧC(C TGç:H8 CC$BJ6Xdn(8P @0`C(C =JX+<HXPdj "(ܧP`C(C =$X+<HXPdj "(tѧoPCREPP@  RP "P  8#X@o3tYX@ 4T08t XPP@P``XTP TPT@A0`A` "8X (8X0 "8P0 8(P P0 `288@argument is not a compiled regular expressionfailed to get memoryunknown or incorrect option bit(s) set | `D (0 D r(\>D FGCC: (GNU) 3.3.symtab.strtab.shstrtab.rela.text.data.bss.rela.rodata.rodata.str1.2.rela.eh_frame.comment 4 Px  &,6T1   >2llRM$  \ \ le    I   &D,. 2>=study.cset_bitset_start_bits.LC11.LC13.LC17pcre_studypcre_malloc4   f   $(0,04H8<d@dDLHLLdPdT|X|\`dhlptx|: 88 $(H,n048<@DHLP4`pcre.o/ 1073241682 0 0 100644 50836 ` ELF4( P4X X4P4PCRE"# t/3:T P0DX @83 P0@ !X41T0:01, PCRE "§U t30X0U@($@XX$:T PP(,PX @ (#P P!T * ! ç PPX((P4U $ XX"P0!X4 XmJH/7@X HC@t 0P$m4:U0$Z(H/JU0 $0XX#JЧT@,ɧCU$U($@*CAJЧ.$CU$U(ft:X0 CJ\A!0 (AC @CAA"0JБ tN I$AeCPH@N7HUHC@Dt (HU0$JW@48Q@4/H$&X0 CA!0 (C .`*.@$AJ$CA!0 tڧAJɧP4X@C *8CQ@Q+C0 AQ@P*C0 AQ@Pt}8 *,8#X4C }8C1@*18C0 AQ@P*C0 AQ@Pt}11Ő} }C XAq8pH[ 1CT 02:AqP ptG(C .}*A [HA@B(C JArPptC ,}Y0$Y@P0P@C0 H=RC0P(#*U $< XX"D8C0P#X$!P0ZۧCP(C PQC0P1 X 8C1 S%0$L=PC0 (#.K(LU $ X X"X,9 "DC(C =C0!X@𘘟,C!C0 C(C Χ!(C0#*U $) XX"HC@C@8C0(C CAtfDt1tC(C C01X 8C1 ç^P4RX@CP('-L%!1:> 8C0P0CP10 C@LQX4(C!@(CPC @ ;X§,P8H *§MXCP^KWC(C (8X6C(C =(XCPX(8HC%X, *§D(X@𘘏,:H "ǧ%*U $׉ X X"(C !*<:!U $ XX"C0(C 0(( DPX @+DX9J "( X +(X@𘘏0^*C *CP Q0X@@ A*CP At!0] tP 0*CP  XPXpXT <0)KCt(X@|X3p ",toa|; K1>@X  P@PPPXPP ħ(!P0P8PP`P P0P0 x(xXP0XPP0P0P0PPPPPt8P0XX@DÇt dX AQPP# UЀ$ JX tX1 XX0Ч(XPX0X@poP(P XX!*P P?hHLP@ܧt"XPX PPPKXPBPPPPXܧߧ88`UТPX($PdAPlXhA&A`APX@hPptPx "3X@ܧNGmXܧKP$.F*G&XܧAXX)(XpX  (EDPX ./D 𼧤PXD8PP0XPPHP@:HC0(C 01J>0tN$NtzXPPPPrX  l*MP X ܧ.E$!8P0PC !*U И$ى XdX"X P) 1P1)twX8BP0PX 8GP0ܧ8C0 >RUX@CSQP8C0 *P :Е)X# 2(C P02:Е)t3X# PPB B0HX  DHXHP@PlXPX@HCPA! %*8C0PP AC @CJRA10tDPt@X̧4(C  C!;[BC BX\,:X@X "X`lXPPTeXXX 8 §X(LP ܧxXP(C .!.=tHCP@ܧXDPPܧX(AP ܧXFPܧ@<X *P *X@@8C A!@ %X 1C *P *01:C AQ@Pt>$B0+XHX BJP@8C 1><ýВ$+P)@P00P4!Xp P!)thX[4lXP7:X 4K "jZplDX@@T|lHC@p@CpX 0A.>PX0NB0:0B@0X$$( @!Y@ P $XP@ c(rzPpXX C *МP t(X0#&LJP@(Pp P,P$ E($DWDF*Z#DX X BX0C 0*B KJ<$:  0A01A&U0D@PB XP4X2R1,!X8C< C[QX00LXHP@P@A@C(!.);0.:,TО:iP0𤧄i$vUmU$`-XX(;C!.).:tXhV`Wкa) 8LP0PݧTЈ BX𤧪X  XTТVPPPPPPP` 9A@Xt@ж@вss$ mt@Цxt@Ю@Ъ{@ТvXP(8P P0X "}tXWqCph+p P` N?ৄ>X@C@Ќ(!..U Ў$§hXO𬧄2XPVPPاtrNhNWXاPۧXB鉼BX@ DtVp(XXPPPp(hX8X0#L* ᧪X<0F>B0BXB0X B Xا PۧZPPا6jB`XB𫧪X@DDY@𨧄BXX[ PPpBXPاħN&X0C0 tϧ X@C@B@X ا*P اɽВu.:qU Д$ .F.Gt^X@[NPhT6X!tU^X8X@X JIP@ا*X0K XPPۧZXا PؒLPZePPZPPX@JP@DD| DFXاITBLf(*&BB jKJ:X  0 A01A !0 D@ Vf:6:JC(C @ C@!b>BB0fB0@B@tڧnh[X ا*?P ۧ\X8XX0,K X0X ا*IP ا*0P PQX=9X03XPUD5*KJ:X  0 A01A !0 D@X DX@DAX0C0(C 01>0tPX00<)X@D$XtNSCt.1X@اJ5P@ۧXBX@𬧪N @B@鉼XPPHX0ا:3P0ۧ}.tX ا*1P اXا/PاX0h C01XCX C B PXXX V(PX8$4*H ᧪XP:[0LPBPB0PBB0>CPΧP8P`P0 PX4KHXP@PPqX0>PXP PHP@PPKXP+C:L.H=DPC8^P0%XxPPX\LDʊ@AP(,0CP0 BPX@C!<0T Ј@ CPBPzPX𤧺P𤧺C]tXt~;X ./X@D진8A0( C0XB& Ȓ78P0X진X .8P0X@NXVV(PXPVPPPPJ6XEt,(P PT[b\X-t]P(C .\O,DE§$, hh LD3@AP(,;CP0 fBPX8KC!20T Ј@ CPBPPzϧJXPP(XPXA X0ԧhX@PX ".P(XPXA X0ԧhX@PX .§ç̧d,*U ЄX@x $ X$X"AP8 C,PC@@!B,P6AP8 C,@@!CPBP6qAP8 C,@!CPBP6YAP8 C,PC@!B,P6DAP8 C,@CP BP6.AP8 C,PC@!B,P6@t XCX@@ X\PEt=X8C0>: >.>=t!XA0I "X0HP@X`:0tP^0X X0;+ "Dx.$(ZXX x UD,X03016APH C 0!CPBP:Fw< Xx 16APH C,PC0!B,P:FwٔէxX00XPPPpX  ҧPHCP@XA0I "tXX: XX P XXPXA X0ԧhX@PX "§D\PXPPX\B$XPX CA" X .9规+XX (CQVPRPPCV P XB$XPEX (ߧ1X(C V P P 8X (C1V02P0HCAV@$X (X0HXC@0V@P@PPXEt[(P PWX A10tK# \t=XPXA X0ԧhX@PX "§(AXPÇ2 t.GX2,.PX0*B0B 0:0 UЈPHP@Bͧ $ɧ(P X\PPEtX@N PkXPPX,X * "yX0X *A0A@XP XP PÇ o htp PXP`P xPX PPP`PtXZ *P TxX8C {#B PXXEPXX *P A|P`ApPhXAA xA@AP7X`Pdl "=X|XX03tX|t'X=X0B0XC ,B XXPtPPzX0<C(C # B0B 1$X>X0[B0XC [ B X *TxP *X)X X8PP X  X#X@ИoB  *P X,XX0x "D BB Y. X X 8P XD0X|D%DX0(*!# D?1PX|X 8 PXX,*;H 8C0 >L=:> 8C0 0C 1>H$H@0I;Z "(C(C =(X@𘘏>L4>A0>F,>G(U$ tȧ(Ut>;I$XPX,*H8 HC@ NLPtX ԧ*YP ԧPاX  4/8JP0P0A0P@XPECP,*U И$i XLX"0МJX@DtXVWЌ(PPP XV Vд)tLtX@DNtX̧P̧A00а0Ь0Р0ФX00H0ШZPPX@৊DJP@XP[CP̧XPXPXP^XPP%AX@Db\PPZPP(C  X03t]tP-%!{PtXZ% "XX *A@XPA0 X@RO@2X00 EPtZPPPCP\[tXA@%; " XPZ XPXX0X@+Yh X0Ŀ?0tŧ.."DXPd HP@ܧ(P=YXX * "XX *A0XPA@ X0RP ?0t~/t4X*&."XP?PtZPPt駊XZ̧XQZPPÇ tXp Xħ(X00@m SXX0<5X8ZC($.a- D#X`8HC0C@P(ZC&0C@!(t $(m DC PCT TZ0(t 3$ߐo.L=>I XP!U PPuP`,P@(PPP`0wXħ A  P$P C@84X>LPP<ç CCYpD8LU08$ É0X4X#X;:*X@(WX`,`Pd "tC(C =ݧ X@oxpTtXX@X pX0@pT p@ X,0/p0Yp@ pH(PpD˧Xp8t`Xp8ZpPYp8XX0p(C!A#  XUp<(X0pCA(AL %'%t Up<X0pCAd`Up<X0pCAtJFUp<X0pCAv0,Up<X0pCAt\Up<X0pCABUp<X0pCAt(X,tXPp< D ŧXPp<Up,0t@.(pHXpDWTU.@.X8X`,*X@(W`Pd "t񴧺*;X@(W`Pd "tX;X`,*X@(W`Pd "t8*X@(W`ԧ8T0,P0,CP,C@kHePdX;:*X@(WX`,P` .("tGC(C X*;X@(WX`,`Pd %C(C =t٧C(C =ǧ(C  C!Y<:Y(Xp X""Dt#8C00C1;:X*X@(WX`,`Pd ;:pTէѧPdX˧*P0P@̧ H(!P 1X XЈ0HCP@8C2P0%,R%* HP@&XDcXPp!AJX0d%:* 0 A01A !0 D@XYh(P X%X0 ?t#X1010X@hNX XX dP P #^88XPp*HC *YЧS*D9CY̧CY̧tX03!XZAA @اA! tX03C0(# X@T0C 0tDX|(C!@P ̧>X03t9X@D4@0JP@*qpqXz' X0 "P p((X P ܧ(Xh(!!  !"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~  !"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\]^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~>~~x:;<=>?@[\]^_` ``@`  @ alphalowerupperalnumasciiblankcntrldigitgraphprintpunctspacewordxdigit4.4 21-August-2003\ at end of patternPCRE does not support \L, \l, \N, \P, \p, \U, \u, or \X\c at end of patternunrecognized character follows \numbers out of order in {} quantifiernumber too big in {} quantifiermissing )conditional group contains more than two branchesinvalid condition (?(0)recursive call could loop indefinitelyreference to non-existent subpatternnumber after (?C is > 255two named groups have the same nameinternal error: unexpected repeatnothing to repeatrange out of order in character classinvalid escape sequence in character classunknown POSIX class namePOSIX collating elements are not supportedPOSIX named classes are supported only within a classlookbehind assertion is not fixed length\C not allowed in lookbehind assertionunmatched parenthesesinternal error: code overflowfailed to get memoryregular expression too largeparentheses nested too deeplymissing ) after commentmalformed number after (?(assertion expected after (?((?R or (?digits must be followed by )unrecognized character after (?<closing ) for (?C expectedsyntax error after (?Punrecognized character after (?Punrecognized character after (?missing terminating ] for character classunknown option bit(s) setthis version of PCRE is not compiled with PCRE_UTF8 supporterroffset passed as NULL | `D (D <PD TZD hD D D D D dD $xD f$8bD N`D $xD ^(D ($D Z$6D V  D V D&D b(h*D  D (!D b(D jGCC: (GNU) 3.3.symtab.strtab.shstrtab.rela.text.rela.data.bss.rela.rodata.rodata.str1.2.rela.eh_frame.comment 4jD  +j&  1o;oH6)  C2W Rŀ  ajlpZ fM# +P87J[\c@wL  x b  ' 6*$D-6P/]04&tA~BT! Vj~nH6p>4@~#B*(18?@FMT[fbi"pw~h~ $*06<BHN %P3Z?GO1\*\cpcre.cOP_lengthsrep_minrep_maxescapesposix_namesposix_name_lengthsposix_class_mapsdigitabpcre_default_tablescheck_escapeis_counted_repeatread_repeat_countsfirst_significant_codefind_fixedlengthfind_bracketcould_be_empty_branchcould_be_emptycheck_posix_syntaxcheck_posix_namecompile_branchcompile_regexis_anchoredis_startlinefind_firstassertedcharmatch_refmatch.LC14.LC25.LC28.LC31.LC33.LC45.LC47.LC79.LC81.LC84.LC5.LC89.LC92.LC96.LC99.LC102.LC104.LC106.LC110.LC114.LC118.LC120.LC143.LC145.LC159.LC161.LC163.LC170.LC172.LC175.LC177.LC179.LC181.LC183.LC185.LC187.LC189.LC193.LC196.LC199.LC202.LC204.LC0.LC1.LC2.LC3.LC4.LC6.LC7.LC8.LC9.LC10.LC11.LC12.LC13pcre_mallocmallocpcre_freefreepcre_calloutpcre_versionpcre_infopcre_fullinfopcre_configstrncmpmemmovepcre_compilepcre_exec"\T#X \$`\d%h&l\\'(  $ (  ,( 08 4    P c  ) *  $+ (, , 0L 4- 8  <. @ D H/ Ld P0 T\ X1 \2 `3 dc h4 l p t5 x < |* 6 7 H* **8*9---/ /$/0<0@040D 1d:1h;1l<1p1tL1x1|1 1=1>1\1?1@1A1B1C1D1E1F1 41 l1G1 1H1Z1I1*1J1K141\1-1041/B\BTB`dBd^BhZBl\BpBtBxAB|(BBBBBtcZcBTc\PLTMXN\O`Pd,hQlRpStTxU|VWX[]\`d h,l8pntx|:2:BxxxxxxxxxBBBBBBBBBBBBBBBBBB BB B$B(B,B04B8B<@BDBHBLBPBTBXB\B`BdBhlBpBtBxB|BBBBBBBBBBBBBTxx*  $(,048<@DHLPTX\`dhlptx|xTTTxx  h h h hLLLLL LLX h h  h$ h( h,`0 4 8 < @ D H L P TX \ ` d h l p t x |                    h     D D D D h h    h    $ ( , 048 < @ D H L P T X \ ` d h l p t x |                                  B B         $ ( , 0 4 8 < @ jD jHL'TP'TT'TX'T\'T`'Td'Th'Tl'Tp'Tt'Tx'T|'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T 'T'T'T'T 'T'T'T'T'T 'T$'T('T,'T0'T4'T8'T<'T@'TD H'TL'TP'TT'TX'T\'T`'Td'Th'Tl'Tp'Tt'Tx'T|'T'T'T'T'T'T'T'T'T'T'T'T'T'T 4' 'T*'T'T'T'T'T'T'T'T'T'T'T'T'T'T'T 'T 'T 'T 'T 'T 'T 'T 'T 'T $'T ('T ,'T 0'T 4*R 8 < @* D H* L* P* T* X \* `* d* h* l* p* t* x |          *   $ * * * * 8 * * * * * * * * * * * *  *  # # $( $X $ $ 0 0 $0 (0 ,0 00 40 80 <0 @0 D1 H0 L0 P0 T0 X0 \0 `0 d0 h0 l0 p0 t0 x0 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1( 0 0 0 0 1( 1( 0 0 0 0 1( @d 6B 6B 6B 8P >p > $> (6B ,6B 0@d 46B 86B <6B @6B D6B H6B L6B P6B T6B X6B \6B `6B d6B h6B l6B p6B t> x6B |6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B > 6 6B @d 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B 6B $6B (6B ,6B 06B 46B 86B <6B @6B D6B H6B L6B P6B T6B X6B \6B `6B d@l hA l< p=J t8 x=J |=J =J =J 9H =J =J =J =J =J =J =J :& :& :& :& :& :& :& :& :& :& < =J ; < < =J =J =J =J < =J =J =J =J =J =J =J =J =J =J =J $=J (d 4= 8>L <>L @>L D> H>L L>L P>L T>L X>L \>L `>L d>L h>L l>L p>L t>L x= |>L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >L >$ >L >L >. >L >L >L>L>L>L >L>L>L>L>L >L$>L(>L,>L0>L4=8>L<>L@>LD>8H>LL>LP>LT>LX>L\>B`>Ld>Lh>Ll>Lp>ZtCxD2|DHDTDTDEE4EhEEFFFF\FFFFG\HHHHHHHK6K6KtKKKKKKNHNHN NNNNN N$T(T,T\0V4V8V<V@VDVHVLVPTTTXV\V`Y\d[Ph[l[p[t[x^ |^^ ^_>_f`\b`b\CjRRS.SjSSO0ROPP,PDP\PtOOQHQQQR8RtPQ0T TTTTT Vv$Vv(WV,WV0WV4WV8WV<WV@XDX,@XlL  < d |  *-$/H04l1\ABTcusr/lib/libpcre.la0100755000000000000000000000127407776057163013123 0ustar rootroot# libpcre.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.3 (1.922.2.110 2002/10/23 01:39:54) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libpcre.so.0' # Names of this library. library_names='libpcre.so.0.0.1 libpcre.so.0 libpcre.so' # The name of the static archive. old_library='libpcre.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libpcre. current=0 age=0 revision=1 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' usr/lib/libpcre.so.0.0.10100755000000000000000000013340007776057163013600 0ustar rootrootELF 44 ( , 4dtP$$%>984+)<%=67/."'5*#;,2:30! (1$-&H(d  @  8     lt| *z"V /  sK X Zw: n|Qd6  T` 5 ;"$f ^`  F |  J A^  J (: `  t _DYNAMIC_GLOBAL_OFFSET_TABLE___gmon_start___init_fini__cxa_finalize_Jv_RegisterClassespcre_maketablespcre_malloc__ctype_tolower_loc__ctype_b_loc__ctype_toupper_locstrchrpcre_get_stringnumberpcre_fullinfostrcmppcre_copy_substringpcre_copy_named_substringpcre_get_substring_listpcre_free_substring_listpcre_freepcre_get_substringpcre_get_named_substringpcre_free_substringpcre_studypcre_calloutpcre_versionpcre_infopcre_configstrncmpmemmovepcre_compilepcre_execlibc.so.6_edata__bss_start_endlibpcre.so.0GLIBC_2.1.3GLIBC_2.3GLIBC_2.0 is ii( ii2 xD H L P T X "\ (` .d 4h :l @p Ft Lx R| 1% , 5 6 8 <      ! # & + , 3 8 9 oTPXXX %X0 M %LX0 M X@oxPXPXX  XX X X XX X$X X0X  XCZ`X0 J[A!0 (AC Z `@CAA"0JБ tN H$AZCPH@N7HJHC@Dt X(AP:U0$JW@4*Q@&XH$CZ`X A1 0 8C0>`:>@$AJ$CZ`A1 0tاAJɧ,mA@C XP*8CP-C0 AP*C0 APt}8 *,8#,C }8*8CPC0 AP*C0 APt}01o l|j|}AXdPP0`C 8HYA!  1CT 02:AqP ptO(C .}1YHAA@B(C JAqPptC XAP+oY0$Y@XX`P0P@`C, mH=RC0P(#*U $AX AX"GD8C0P#X$!P0ZاCP(C PQC0P1 X A1C Q%, 8oXn$L=PC0 (#.K(LU $X AX"GX+8M"DC(C =C0!X@𘘏+C!C0 C(C Χ!(C0#*U $,X AX"GHC@C@8C0(C CAt_Dt1t|C(C C01X A1C Y(<ARX@CP('.L%!1:> 8C0P0CP1; C@LQԘ((C!@(CPC*@ ml;X+P8HM)N8C0>K[C(C (99C(C =(8C0XAS(8HC%X+M)D(X@𘘏X+9HM"#*U $X AX"G(C !*KJ!U $X AX"GC@(C @(( hDPX @* (X@𘘏X8IM"(򿿰X *吽,^*C *CP Q0X@@ A*CP At!,] tP 0*CP o dX`AX C`sAPP `X!d95X `CqGXt(X@oXdX:XM")tocvvX@v>sdTvm`u u߸uduuzuuTHu,lHttj|; K1>@ Xp Xо P@PAPPXP̧P ħ(!P0P8qPP`P P0P00x8xXP0XPP0P0P0PPPPPtXPPXXCt qX A! P⧮#8UЀ$ Xt:0AX#GXX0X@Ч(XP0@X@op(P XX!*8P PpP0 ?XLqPPܧt$XX0X P0KX0BHXP@PP 0PXܧߧ87`UТPX($PdAPlXhA P ph tPxX APA`X@M"6X ܧ.GpX@ܧXNKPP$1NF-NG)X@ܧNAXX) XpXPAPPXPЧ(P=DPX/D 𼧤PXDPP8P0(P 9HC0(C 01J>0tN$Ntw8P0P0oXlX@AP@*MP XܧE$PPHC@ $*U И$Xd AX"GX P) 1sP1)tfXBPPX@GPܧC@RZA!X@C"!P8C0@JP@:Е)X# 2(C P02:Е)t3X# HP@ PB B0HxXDX0AP0ޒHX(P P\XPAX@HCPA! %*8C0PP AC @CJRA10tDPtAX2(C  C!;[BC BX\+9X@XM"X`{XTX AP UXXX 8MXXLPPܧrXP(C .!.=t(CP ܧާ8DP0ܧXXAPPܧXHFP@ܧ:<XPA B(XP@C $8A"P &X 1C *P *01:C A!P t>$ B0HP@ XHX BJP@8C 1><ýВ$P)@P0DPH!X` P!)tX[HP@LPXPL6:X HKM"X@ Z` P@DXTVX@HC@`@C`X DA.>PX0NB0:0B@0X$$( @!Y@ P $wXP@ 6(bjP`XX C *МP t(X0#&[ZPP8P`0PB0BXB0X B Xا PۧZPPا6jB`XB𫧚X@DDY@𨧄BXX[ PPkBXPاħN&X0C0 tϧ X@C@B@X ا*P اɽВt.:pU Д$ .F.Gt`X@[NP,hT8X!tU^X8X@X JIP@ا*X0KMXPPۧZXا PؒLPZePPZPPX@JP@DD| DFXاITBLf()&BB iKJ9X  0 A01A !0 D@ Vf96:IC(C @ C@!b>BB0fB0@B@tڧhh[,X ا*?P ۧVX8XX0*KMX0X ا*IP ا*0P PPX69X03XPUD5*KJ9X  0 A01A !0 D@X DX@DAX0C0(C 01>0tP,X<X@D$XtNSCt.1X@اJ5P@ۧXBX@𬧚N @B@跋XPPHX0ا:3P0ۧy.tX ا*1P اXا/PاX0h C0-XCX C B PXX X V(PX8$4*HMXP9[0LPBPB0PBB0>CPɧP8P`P0PX4ç(8P P0iX0>PXP POHP@HXP@PPCXP+C:a.]=YP𤧨C8^P0 :XPPPX\JDЊ@AP(*0CP0 qBPX@C!:0T Ј@ CPBPX0:P0PX𤧺P𤧺C]tX@DtXP^;X/X0 3진8A0( C0HB& 7(P X 진X`(P X0>XVV(PX@V@XP@PPJ0XEt&(P PR[g\X-t ] P(C .\P*DI$* hg JD7@AP(*;CP0 fBPX8KC!20T Ј@ CPBPX *PP ˧JX(YXA X0WhX@XM".P(XPXA X0ԧhX@PWM.ŧa** U ЄX@P$X$ AX"GAP8 C*PC@@!B*P6}AP8 C*@@CP BP6gAP8 C*@CP BP6OAP8 C*PC@!B*P6:AP8 C*@!CPBP6$AP8 C*PC@!B*P6q@t X𤧨CX X\PEt;X8C0>: >.>=t!XA0HM"X0HP@$(:0tP^0X X0;+M"Dq.$(PAZX PXhA" YD-X0$33X0(1APH C 0!CPBP:Ff< X( P X0(1APH C*PC0!B*P:Ff֔ҧhXXPPP$gX5PHCP@ XA0HM"tXX:tXXA X0WX@XhM"D𠧨\PX  X03\B$XPX CA" X@N9规+X (CVP8C1V0#P X@B@$BXPX (ߧ1X 8C0 V0P0P0HX (CAV@BP@XCQVP%X (XPCPVPPXEt[HP@PWqX AQPtK#!\t=XA X0WX@XhM"'@XPC1 t.GX0>2*.PXP*BPB P:Pp UЈPPBͧ $ɧHP@X\(P EtqXP^ P&PX,X *M"wX0X *XPA0A@MXPP _PP𤧨C o XXj`xpPXP`P xPX PPP`PtXP@Z *P TxX8C {#B PXXEPqXX *P A|P`ApPhXA P dA xlA@APX0X`M"=X|XX03tX|t'X=X0B0XC +B XXPtPPxX0;C(C # B0B 1$X>X0[B0XC [ B X *TxP *X)X X 8PP X  X#X@ؘoB  *P X+XX0xM"D BpB pX.X X A8P XD0X|D%DX0()! D?1PX|X 8 PX+*:HM8C0 >L@:> 8C0 0C 1>H$H@0H:XYM"(C(C =(X@𘘏>L4>A0>F,>G(U$ tȧ(Ut>:H$֠PX+*H8MHC@ NL?JN HC@ @C AN8$80@9XJM"(C(C =(X@𘘟NL)NA%NF!NGU$ ţ(ڧN(§9 ՀI:APX+*:HMH2C@ NKHL$*U $ X AX"G!X@𘘏:DC0tC(C =֑C0V:XW@J#@:M"DDŐopTSSeH ٤SRp?RS S&S>RRRS`KJRRIXR4@><RRPHHlX1<O@PCRE@ pXاDP A(P PP@PPP`PxPPPP(BUP @wXȧ(P tiHŀHt`X@DSXX PP@P̧hC` 8PfPP0P0P tX0AF0@{XPZPPhC`ftzYpм$[X`XܧX`زRjX<gj&X0 "8XTTR P P` A`X P PA(P @P P A PPPLPlXhA@P@x8H8P pP@P@dP@hP@tA@`AP(MXtX XlX AP XP XpX0AP0 XtX@AP@XĿt5D$X0 1HA X(C!@$HV0@P0 +X@ oH(X|APXP):HM" ȧ/D82! X(C!0#H  @ XЀ:)HM"P XЄ)X@8M" Ч~Xx+X<X@0 XPX@[P(PP@Xd(X@AP@X\(X0AP0yn#&Xԧ*ܧU ЈPԧ$)XX AX"GXhA X@X0XXMbX Ŀ/ tfDh\Pz8n\&XP$%ZPPhXC` A!` ⧾$ZPP{$XPEPtڧZPPԧX0AF0@XPħn#'n\XA X@X0XhXMXĿt8"ZPXQZPPhC`fn tntzn$&*.X0$a Y PP XPz{PtXZ%M"XX *A0XPA@MX0RP ?0tտ/t X.zXP?PtfZPP`ЌtzMXPE?P8tXPX0U0и$C@BCXP:PqzPP0XTXPX0AP0chC`P&*U А$9XP AX"GZPPC@)$*RP *CP)tPtX$X@AP@RPfA C@X(A105TZPPC@zA104:SP0:CPAA@t)P[X@X AP TZPP?PtCP=@!<<8TZXDPPM)PtJzP@#ZnRPPX(A0X *P *C A! tXP)PtC P֧zД ?{tz hC`Pn{hn*Zn+Jn?88P0P0/tz Rq+PtZzRX0q22R;szZP(P PPħ8HZP0P@Z(PXZ%M"tXPXX *A@XPA0MX@RP O@X,iZPPC@=!tz5X<ڧJJP@X(A0X RZPPHC@ $AA@t.)tz;X0hZPPC@Ж&ýД$X0ZPPHC@A!0 t)X4X8:$*P X0C@RA304:SP0:CPAA@t>PtX ا*YP اPܧX4CJP@HP@P@A0XPhEC`P&*U И$nXL AX"G0МJP@XtXV(WЌ8P P P0XV zVдn)tAtoXtfX Ч*P Ч^A00а0Ь0Р0ФXHs0ШZPPXzPX 8XPC2[P0ЧXPzXP&XP^XPP!A<\P,ZPP(C  t]tPz!-zX ?EPtԧZPPΧCP\[tXA@%:M" XPZ XPXX@*X0XhMXĿtڧ.."DXP (Pez^XX *M"XX *A@XPA0MX@RP O@t/t4X*&.z"zzXP?Pt1ZPP+ztzXZpЧzXQZPPhC`fn tX AP̧XKXIX;m SXX0<5X8ZC($.a- D#X`8HC0C@P(ZC&0C@!(t $(m DC PCT TZ0(t 3$ߐo0L@H-L-R,=t=T<==4;L=>I _XXXP!AU PPPP,P`0P@(PPP`4Xħ A  P$P C@84X>LPP@ CCXp,YpD8LU08$ X40AX#GXH;:P@d`)X@(XP,X`0M"tC(C =٧ X@oxX@,@T!_tXp,XX@X0@pTX pMp@ X04tX,0X,Y@ X , H(P DX@,X@8tLXP,XP8ZPPX,XY8X0(C!A#  XX ,U <(Xp,CX0pA(AL % j%tXP,UP<X0PCAMIX,U<X,CX0At/+X0,U0<X00CAfXP,UP<X0PCAtJX,U<X,CX0A,٧X0,U0<X00CAtX0tX ,XP < DX0,XP0CX X Xp,XPPhXP(PCtp8XtZP(X0p04t@4X8P0d`:X`0)X@(XP,M"teH`P@d);XX@(XP,M"tNJPdX`;X`0)X@(XP,M"t1(P d:)`X ,XP@PUX@ T@ @@ X Z2 0 A01A !u0 DPpX@X0,Xp,E@X0 X 09[0p8Xp(pXq Pt P4 $> P(8Xp,pH(PpDXHX;:P@`PPd)X@(XP,X`0M.?"tC(C C@A@ҽABXpħqtC(C =X,(HC@קP`X(;:P dX@()XP,X`0M.R"tNC(C =X0ħ14X@,C(C U@8PdX;:`)X@(XP,X`0M."tC(C C@A@ӧF=tC(C (C .=X0,.>(0HX0D?<\.@4X`Pd8X`0)X@(XP,M"t🧺`Pd);XX@(XP,M"tXXPPd`;X`0)X@(XP,M"tkx)8`PpdΧHT@0P@0CP0C@bHiP`X(;:P dX@()XP,X`0M.*"t+C(C X8P0d`);X@(XP,X`0MC(C =tקC(C =ŧ(C  C!Y<>Y(Xp, XpX""Dt%8C00C1;:X`Pd)X@(XP,X`0M;:XP,PTѧX(P d`):X@(XP,X`0M"trC(C =C@;:C0(C 01=0XH:P@d`)X@(XP,X`0M"}X p :Xp0* I[@p8XSX3P0DX2XppLPPHP0LPBXH;:P@d`)X@(XP,X`0M"tXP,(PpPLCC =80X PXDXpHPs P XP X0LP1 ̧Ȑo@HPCRE;X AP`ȧHoX`pP(FP P P P PPPPا(t:7X@tD-HX 3P lP@P@X00l00 tX x8 ] Xp HCRAP`PPXPPPXx8(T T0|PWTP HX |P0P 8*@JTPP7X`TT`P0P@PPP (PP`PPP 𼧄 X ̧8 ] MptX ̉ 8 ! HYxP0xtP@PX̿_p%X005#!:*2D#! HP@0:&Xtp@H! 82HA>P0P@Чçp H(!P 1X XԈ0HCP@8C2P0%*R%* HP@&XDCX "$!(X0|C C YЧC(C#Y ЧtXDK$EX "+D*U 9X03)C *Yԧ Yا)DX@Dt (X@Ho(XX pX<X@0 *)P PdXHP@hP@`APhPX0+HX`M"tX03t$XPpK.tX "BX0x>eXPp!AJX0t%:* 0 A01A !0 D@XYx(P X%X<X@0 ?t#X1010X@xNX XX tP P #W88XPp)AC *YԧN)D2CYЧCYЧtX03!XZ٧AA @ѧA! tX03C0(# X@T0C 0tDX|(C!@P Ч7X03t2X@D-@)JP@#ZP!X X<X0 "P p(8Xp P0(Xxҧ(,3XAPX XtX@𘘿o3PXͧ% X0 M X@ox*+?{^.$|()[d,XVVVV~VVVVVVVVVVVV&VVVVVVVV.VVVVVVVVV|||VVVV& 8^argument is not a compiled regular expressionfailed to get memoryunknown or incorrect option bit(s) set:;<=>?@[\]^_` ``@`  @ J`jv D`X`h4~~~~~~~~~~~~~~~~~~,~,~,~~~~,~~,~~~~~~~~~~>~~~~~~~~,~~~,~~~~,~~bZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZbbbbBBZZB&&&&ZZ.66666666666666666666666666666666666b666z.j666666666666666666666666666666666666666666666666666666666666666666666666666.@ XHHHHHHHHHHL`pf$PPXXXXźXXźXdźzX,ttttttttttX$XX`¤DHbrr.jǢNȘȲVʖ *NNNNNN**hььььььpp׶^^^^^^^^^f6..X& fԼ<|ռԶѤ0фќ6vӶ6\ֈֈֈֈֈֈ^^,,,,,,alphalowerupperalnumasciiblankcntrldigitgraphprintpunctspacewordxdigit4.4 21-August-2003\ at end of patternPCRE does not support \L, \l, \N, \P, \p, \U, \u, or \X\c at end of patternunrecognized character follows \numbers out of order in {} quantifiernumber too big in {} quantifiermissing )conditional group contains more than two branchesinvalid condition (?(0)recursive call could loop indefinitelyreference to non-existent subpatternnumber after (?C is > 255two named groups have the same nameinternal error: unexpected repeatnothing to repeatrange out of order in character classinvalid escape sequence in character classunknown POSIX class namePOSIX collating elements are not supportedPOSIX named classes are supported only within a classlookbehind assertion is not fixed length\C not allowed in lookbehind assertionunmatched parenthesesinternal error: code overflowregular expression too largeparentheses nested too deeplymissing ) after commentmalformed number after (?(assertion expected after (?((?R or (?digits must be followed by )unrecognized character after (?<closing ) for (?C expectedsyntax error after (?Punrecognized character after (?Punrecognized character after (?missing terminating ] for character classunknown option bit(s) setthis version of PCRE is not compiled with PCRE_UTF8 supporterroffset passed as NULL;#hpl?@abcdefghijklmnopqrstuvwxyz[\]^_`abcdefghijklmnopqrstuvwxyz{|}~  !"#$%&'()*+,-./0123456789:;<=>?@abcdefghijklmnopqrstuvwxyz[\]^_`ABCDEFGHIJKLMNOPQRSTUVWXYZ{|}~>~~x "(.4:@FLRzR| `(RXD r(DVD ZpWD (X fD Z(XHD VY8:D Z(YTD V(4Y`D Z`Z:D ZZ8D (ZHD r(_JD N`D `D aXVD 8b`D (LbD FxexD (fh:D dgxD $hD diD $jxD f$@khD Nhl D (lD f(m$PD (H0D Z$L:D V ,` D V$P\0D b(xd6D  pD (#D j( D n (H <  @  ooodo d  $ D d GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3.shstrtab.hash.dynsym.dynstr.gnu.version.gnu.version_r.rela.dyn.rela.plt.init.text.fini.rodata.eh_frame_hdr.data.eh_frame.dynamic.ctors.dtors.jcr.got.sbss.bss.comment  HH((<!odd|.o@=   G @ @  Q \L 8 8W ]8ck$y lltt||XXusr/lib/libpcreposix.a0100644000000000000000000001643207776057311014024 0ustar rootroot! / 1073241801 0 0 0 54 ` zzzzregerrorregfreeregcompregexecpcreposix.o/ 1073241684 0 0 100644 7268 ` ELF 4( +XXP*X; "U (X@𘘏XX+o.cP$O XXX) fXp 9`4' §̧XJ(J9 (B!+X@oxXX``(X0IW X4XX X0P X@o §hAPdA@`#P88V0 X "8HP dt XX ` X@oX P (o arPP0P진aVPp U$ApXX ɧh XRX@X p8PhP`Pd "§ţD 255closing ) for (?C expectedrecursive call could loop indefinitelyunrecognized character after (?Psyntax error after (?Ptwo named groups have the same nameinvalid UTF-8 string at offset %s%s%-6dunknown error code | `$jD Z(<D jh.D R(D Z(D jGCC: (GNU) 3.3.symtab.strtab.shstrtab.rela.text.rela.data.bss.rodata.str1.2.rela.rodata.rela.eh_frame.comment 4  +&  162J EH  W R(<  a  jTL  `H"j 8>DJO0TFYh^chmr*w<|v8Rj<X2>p $*F0h6<BHNT.Z<`JfXlfrx~ lP.pcreposix.cestringeintpstringpcre_posix_error_code.LC65.LC68.LC70.LC0.LC1.LC2.LC3.LC4.LC5.LC6.LC7.LC8.LC9.LC10.LC11.LC12.LC13.LC14.LC15.LC16.LC17.LC18.LC19.LC20.LC21.LC22.LC23.LC24.LC25.LC26.LC27.LC28.LC29.LC30.LC31.LC32.LC33.LC34.LC35.LC36.LC37.LC38.LC39.LC40.LC41.LC42.LC43.LC44.LC45.LC46.LC47.LC48.LC49.LC50.LC51.LC52.LC53.LC54.LC55.LC56.LC57.LC58.LC59strcmpregerrorstrlensprintfstrncpyregfreepcre_freeregcomppcre_compilepcre_inforegexecmallocpcre_execfree Lt`x |N OPXRTUW N$X(Y,   $(,048<@D H!L"P#T$X%\&`'d(h)l*p*t+x,|-./0123456789`:d;h<l=p>t?x@|ABCDEFG#HIJ~ v@llPusr/lib/libpcreposix.la0100755000000000000000000000136307776057165014207 0ustar rootroot# libpcreposix.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4.3 (1.922.2.110 2002/10/23 01:39:54) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libpcreposix.so.0' # Names of this library. library_names='libpcreposix.so.0.0.0 libpcreposix.so.0 libpcreposix.so' # The name of the static archive. old_library='libpcreposix.a' # Libraries that this one depends upon. dependency_libs=' /usr/lib/libpcre.la' # Version information for libpcreposix. current=0 age=0 revision=0 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' usr/lib/libpcreposix.so.0.0.00100755000000000000000000002102407776057165014662 0ustar rootrootELF X4,4 (\\\)\)\++dtP(((44%0,./$+"(! -#'*&%)6  |  X  , ( )\+ +,,,,--+^"/ |n  @- 5 e   ;"- ,- }> u`J  _DYNAMIC_GLOBAL_OFFSET_TABLE___gmon_start___init_fini__cxa_finalize_Jv_RegisterClassesstrcmpregerrorstrlensprintfstrncpyregfreepcre_freeregcomppcre_compilepcre_inforegexecmallocpcre_execlibpcre.so.0libc.so.6_edata__bss_start_endlibpcreposix.so.0GLIBC_2.1.3GLIBC_2.0 is ii)\ )\)` ,* H* \* r* *$ *( *, *0 0*4 V*8 h*< *@ *D *H *L $*P J*T d*X ~*\ *` *d *h *l *p *t >*x h*| * * * * * "* ^* j* * * * * .* J* r* * * * ,* .* >* Z* h* v* * * * * * * * * + + ,+ :- # -( -, -. , , , , ,# ,& ,) ,+ -, -- -/ oD"PPXXX %HX0 M %X0 M X@oxPXPXX  XX X X XX X$X X0X  X 255closing ) for (?C expectedrecursive call could loop indefinitelyunrecognized character after (?Psyntax error after (?Ptwo named groups have the same nameinvalid UTF-8 string at offset %s%s%-6dunknown error codeBJRRR:;0 Ll)\,      H\r0Vh$Jd~>h"^j.Jr,.>Zhv,:zR| `$0zD b(@ D rld>D Z(D b(D r |  & ,  ooo6o@+  $ D d  $ DGCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3GCC: (GNU) 3.3.shstrtab.hash.dynsym.dynstr.gnu.version.gnu.version_r.rela.dyn.rela.plt.init.text.fini.rodata.eh_frame_hdr.data.eh_frame.dynamic.ctors.dtors.jcr.got.sbss.bss.comment \ &!o66`.o0=0 G   Q | |\L W X X]8c,,k((4y)\\+  +,,,,H--Plusr/man/0040755000000000000000000000000007776057301011160 5ustar rootrootusr/man/man1/0040755000000000000000000000000007776057301012014 5ustar rootrootusr/man/man1/pcregrep.1.gz0100644000000000000000000000355207776057166014337 0ustar rootrootv^?pcregrep.1uWr}Wt0S%1LlJv6U ! %+_$E[>}NT^&fLCs$?-΄jѭ]Wt .fbdۻr3m:oJ[okݖ|9SQŖ1XSO@gs>xK*2٨dAo10T[8Xnbh~Fߔ7]$˱? ڌ})2"׺J!s^`f7Yax{0 "D¦&Xlx1QpF~ov&iHpκE`mJ3\lm۔j#c6,!:3 [)Y3f8`C~CkIP[,a :ezVx5vpY0矘џs@IZuzݶ6"&Tl:c/"g<צjlJ҉?LI.1)9 ]U$ۈPи鑋_Go8N%qc $ n/%aqR5XZo-z4w4oNLFaft6SKZ\7[XĦökbԸ~dN1. V̛} L0YW}M*٭QSGnCr{(,B2Gr%XrVZTt u[8ThʲH0h_qAFΓ]`CrӍ[J~fRpNCBY [TĤQ^i fk˅(kPzx]nû`rSLw}cݷF '"KB`arhgE1KV}ƽNQ>oѬ>ԽC>|4h,f9jTXz2M&#yrn\ЄPLMIt`{f)Qt-PLJw M?\w'Cw@r ]"E/s Jfd/p=~G-Վ[P_ӕX2vs%^CxSq Lf}9ʀ Zjc3Pcf+~d~!72j4*!Ow8_:+GSuuFr^+U_NLٍ~0~]Ra7^X)Uᦵڵ-f=Z|֙dES]cs-m*xp"̨}5:jHnjcfMaf{*wmk\,=_B{ tc-=f>'ں+a-{l'YcʜԠfvOȯW8Qfk^>CKolVys0*]V-IDbjlf:|500m{bs ~#qk`-|O@朑8LoΈ CgSiGSѳZJs5"Pt e+>XĵUY5ٷ&WQ4O޴90WdPTo%9HD ~! :ݽھݣd8e='ã (r@Byaņ{m4Q MIpt1#HȌm4ԧ)`]I@j(6_@W6bxޱQT3 m,jZ+2+e[ٜ~^%yϪ<-(F"'66=:[f^-4 RfU.&gDYUX ޏW3VӵkjL֛tc~%fw6_O2lfUrJtx0Fo%-قm8` qy^>ClR )A|vr;V}tw1>8]O..x}xtn.}xVA!_ް̚#A¶lD ({&&R^0S6瀁\UV$`Ua[&~7įNFetǟȥHa'gnF+3tuy瓻}= zp3Qf9TBajD~#P I{M[ g_Sxl`o!5N0>4ͩڌLbd%ܗH8b D2z^19ȧ5G\s=|ϒiWF,[V_L'x/-o,_ I4 ,MV1"5o 1PZ-y0)I IAdA⠓^̕KA4&c@ NDD,L-5fOӷ){Qac.R" &hJ%H5Ar c&~܌Y"؅ı{1BXbJ&`z Vz|y2HB*ipTqF_$^uef~#]j&"O]I!ԩ 9*ņ4=B [RU Ѭy @OĠ U_PJDF!@YWĒs#޸@ Zb'+WV`zqeccVE;8WŬV=p2da| Be_D#Lixgͩ\tQ#FQ5?F< _ŤO}8)*z/..ZZEBŞ-#.  >CJ@F L%&S*x;j2ˆe fA@UTcOu bp^̟b5pSHJoyp9iNԓC0UI/JU/K!@r8W_Vvs < LjV8"`z ܣmKE&>i]%ҍnS5̻aQՓn NkPn,N*gGГy-ljy@NDK˪ܐrQhCd)QlW4){gb^Jl<+lO1̗â}ӥ!t匛ч*y%"f ݒHISEm _z(C;2w($ 鮤k1|=Mv7~'KOXйZro(]k|{nɢi~V[7wµK7#ZR(rVHxc`B&X,Pp&(YĽ)\7hp#l:$V܆8qJS8\>';nh>gGg2F/ha/@t[r`OWw @b@1/Dv~!@PE%w Tb/ N(;ƬC ip->НFb7;<<|6 "w_)ʇ3M%V #Wj&#-'":XfUW0{'ٙ0z0=%$9 ]8ʶ}j϶~f]G@\r1QM [g'  {Zv`9| +sWUG>$ 0!1izҥ}:t@5oI^f_\ vie`Z&+鷷-ӻ$F=ega!$A(GwbllZ*fB+4:O4NBOUɎ!VHcȝkT==\3p:q(Kc?m R9j$4z .G ,nqڌ#w)g WLmo 8]Q-P+q|Nyk8j^\dL [קn8)\懳\rqk~Zǧ)̭"i'=! 4~Ua*k-#.w+Adgi3_?xT)ZuTےPJmt%~rh!;DmϼG"#]OJ1+%P{_ךE 9ЭvCUlȌᑿ ~FOMpq&2}(!m_({ŜY$KqZn[ojS9e;Hb"w@~ass&|5kH z ״׋ֶd<\KWrħǔ(yp{_h8|pv a-xbIW+Ͼ45/lgc B  ,FyJdvΦ{ f"^ѷͰ.^ FG͆xfID5ao*Қ̲²tI1J"DS\5]׽#=ĒЕ"-$YVtHm)@SǍ40B>hg>x8l׀$P tOV^S<Vʾ K/t@mM[7)C]) y/Z<|-9c|x%Jr}㜦H.UvUFe%\ۢ,=0iA) i%^*-$V>,؄~fEDN퇛zɀвE䴊KT 𞮫2t؜L?mNaXqrV@'u76rQ(iw2F܏E ^@ѡ;iƶj\%֩ϧǠjgUnv"IXFjh1W!!M$rl lsǩt;= [r\DĪYƙ< .*G܍է71^4py\JLM ۾$/lb/ J,xL}C'_>,"QGR-|_r}c,z8ZK|_z7c}kG3l2_)!o5|I~yF'/+wB3hW?VmpDŽ;9~Tx= >{|zMy<0MjJ^, ?=u>f{MbsIGHj<2:o,?T}eKv-=6b&=Wr`qf7oQGj/^?Fx+}O8X$--I rpLYջzi_6[=:e&!tR3 袿 8⓱$AʢJ:HӆҜIZ:byX8Bs?Mp%|0/47*Q1qTU5 ңbgwS= \,6`Jh}92K/fg{8G2v}>$܍?^ th~df94ٰV +c6d0om}s<,A{N_!7iMHv.u7ձ>yjT[9*du(4T $:usr/man/man3/0040755000000000000000000000000007776057301012016 5ustar rootrootusr/man/man3/pcre.3.gz0100644000000000000000000000572407776057166013470 0ustar rootrootv^?pcre.3Ymo7_A%v,y8Gq5v`v)-} ɵ̐\"(w<3Lv{!fr* ùJ0oNy3zWJvδ5ofחW>wVfnH㤒N{.orO˥/*]?bA׶yi}zTMZjaɱ2BDa mukI1%˃#''VWZ9-OSxumS8ζkt vȤ|HU_zh|[2qѮ AJ Jr)ɍ($4ڴQ+9y|H6qTA"dDNT` 3T(¸c!JPj^G\|28EMvtnڷg>hk{krm?JZ4)v\%?"F\h˾lw9f2t<@dHB i)zSb嵳vw =A{~aۚM$ ^t2zTUEC(Lie?$BmU+) Yr燉77:3zؖ0o^xvu0jm쓏;xo8amo{:szAp9} r$jl%*}| [ӥ#b N7ufYguKz_zX KO{/ )š6U2bێrՁւ:G`MB6I%{4ms>XL*3ވ8"hl[FKlt:2h/'OVoh[q098Bplj18DfYa mU=C'E ,Hm3 43Q[GVȹAHiP pMHT){]nmB$`zc_GV笣xĺ|uv ,g^4i6lTHy H[`-{&cv\<bPghG5 [j"IZ/=ݹ;1>bt'pV(>|$6v<),8նk {xL3-n@dWzE\T 2gir(Pm\6Fc<кw@ݚ zI+4ӆΝBZ>+<'-<=oj9tęJ,TtRG,To*A5tI-jpR~6!]{H r\`8bH.|sx B |哮qS4"1:!&TKm-!ؚ"X} & t='^BFYfiHu4.ϡʖv}x<kV^N_CaRC{Pc*W:^s8vtH!D 6HQTڰa$VkQ)ۓ D"ẵp7&tD'#~@m M Tv 6g'/`4׬Zw$kA'W[#^nZSD?_ay8g5dt3%Gm Pd }ۇl'#p ߥCF+2J-]IX]xE>p>$>чX9\ӕz^>la ۶[LjLBz_jc@㥐Q* _? [VcDႉ+t^Nct/39"9{Oё3 E[\id"Űq8 Q(+3nt1s@\r4K!WlOyW^sc8žTzhɎr߆m%(W)ۅϷM}U mB++c[P$: Eֳ퉜ynϯJTk)jd*Nz,~R; 1[ɳ~IS4lvM|ՋCz&G!B/* usr/man/man3/pcre_compile.3.gz0100644000000000000000000000165707776057166015201 0ustar rootrootv^?pcre_compile.3}UQ6~y*S% ([L2qB`uhK|3xSX~j )}K03U-ڕM)-ڢsh0d\V"tj}wJge#|37-$>w%TzTK1~)ҏ:2|$"ǟ52ݑ) >N5^6ï"īq:[g>(E3&Yŀ I,0`材vT=!-"+}FZ3Ji鉮V=Ri( 㼭xEX uvK8\7r=oD,^8,-$^MWڊK:rx;4,5C*c! +}KZlGxHI {Rg=ďGxV}JDA%}v ,Q"?S{Ƴ OK:zD*OԆ^G/5U2kWFA[.0 lARrm{V2Xm"HelhHVJ%cpP0o BeG!=A%ZP=Hc=>?Qa!z*΋|:,ǓYA/c5I7,Y|Yɯأ&CCP-X/G@?ʜɔIyIV$VE7|tqІ.(3KQfdUN󸘦keCR*Oa܁UK0%Cqr} èx0ΒB7O JIg`iUe-п] qj|eM NZIWhD # 3M`7;{IN0KZ+_Gw` 'tusr/man/man3/pcre_copy_named_substring.3.gz0100644000000000000000000000114607776057166017760 0ustar rootrootv^?pcre_copy_named_substring.3uTo0~_q ^!>4R:u팕~wv.3o)|Y9b*rtZu^3H;^wGNy\E6*3T_z0k, 1@|U]Zj뇝NBvwz 7uq%G Zj!*0*jsJ^2JuM{|솺F7Z1|<_W1u=O=ZV!ԃUr㘃t dg6Zc%vNcM`"H {“OB< Y WzSf]`/j-r?rTHܖ;/4=H$'qI%C?6p6?f-,%E?gGKz&OY҉4$vה6Ĉ}҅'&Eyb]C,z`&ˤjusr/man/man3/pcre_copy_substring.3.gz0100644000000000000000000000106607776057166016615 0ustar rootrootv^?pcre_copy_substring.3uSM0W \@H%FIAZR8u?-T+7xvC;U X߯rwPQwb8Z!y4hq)e2CY6R O0YVbYmBBh/񸷾HRu zf.)۵,R6<2Ix^# k12/%j߶?RGW.7s^ZuZ‘Q7g8muέE:It g#urW%\BI^V:;c.6N IfmHĿ6?P_/2ϳX% -U &΃ fP /)I uR`Qj[a]:JҚrSכUڔ SJR27 `\Wږmy2!+dLOw0*t ZatJ%1ÞeW(lr28N0y B usr/man/man3/pcre_exec.3.gz0100644000000000000000000000132207776057166014462 0ustar rootrootv^?pcre_exec.3}Tn0+%i]A[p6ECM$2%T~},vy3 FCartR嵨5r["h̛kZ1RcOy/Yi,R!|ƤΒ4)KHemť l,E. c?s,>}V1ƊRtQDa}JT-ֵT5l tu)#WhN6m(b?z%#%=d]+FIӐݡ/wbxrR+QfRZ-j6_'˨9b.r=J p(#X?+}mߢ-DW:qpp_Hz;w}{juZҝ^%>s#dq N#Qc+Q_EaFhz':~:-ʒ_%5f51ausr/man/man3/pcre_free_substring.3.gz0100644000000000000000000000054107776057166016561 0ustar rootrootv^?pcre_free_substring.3]j0z4cK!I]CcRY^Y+9oߵJ(3 yB)3x~\/@K퇠-a7ZE߁0F]oJHF B8m-hBٿ YiM9uLd\Y6nHtjū ?jS1? HS[աusr/man/man3/pcre_free_substring_list.3.gz0100644000000000000000000000054707776057166017622 0ustar rootrootv^?pcre_free_substring_list.3]1k0w]@tl)$K<$1v!(8ɡ=;iݻ'$O;(eBV;8+(JKP4"@.Ξp,xx4N۱Ex PoBolhZz¤;B<DZ9;mDuW.^\U2/N|L> 8Πtb\P8Xգ?&usr/man/man3/pcre_fullinfo.3.gz0100644000000000000000000000144107776057166015356 0ustar rootrootv^?pcre_fullinfo.3U[o0~8*/l)RѥQ &Un|Yz&9w. kHGYI_CD_Bʔ,UK - cּcdqN%^qY [1ܖ/$HS!\9. YmnJ|;u\6 /f(H`8 Wrc^y)'cQE"> bQN턣) hAQn,9ʎ+_q()†3Qk)Tն,1l\n}8p?%Ú꾣w}|2hQն954 >βM_oVj=J B6GZGJ[ta;πmʦ!XRx+(Lk\]ߢE(qFaÇ& z ,>Sƈj/Husr/man/man3/pcre_get_stringnumber.3.gz0100644000000000000000000000066707776057166017127 0ustar rootrootv^?pcre_get_stringnumber.3eMo0 DwYtvYM->10 @ȴ-=Jj_NSKKoV/)] Ot6am+?zo秚o˴T8G:v4t3}.\Z ;Ⱥ\l 5nJ`1#ߨi_I,|Hz){Dg&:4B0@Ҳh`1DX:=7Qِ=$! *jARo^kє 4#kV b_b~4&wh1! .)uâizԓ,Iq=!;NG1,Jo`U$նYOF6%ͫm Dusr/man/man3/pcre_get_substring.3.gz0100644000000000000000000000105507776057166016420 0ustar rootrootv^?pcre_get_substring.3eS0+FewRV6[p H[)2fW`\c6߱IDr{L",*7>lc8hne#l] 68MrTSOiI"CIh ja0꾱( eQe<@* ӡE{\5Y#U{#HԂ蚻}Ї()Vk3UFk,>|RgA:btꕵ*|ünj끷_X=.$%YurqJSR6Ќ>*k8UQ\[gn7PYR21+0?\q BT$%͢q}[a= tȚfB sy70|Aqsn:$o;A~\H+ 9y%m=4C`G=P0Qb_)x@E6EVlo dCfـh4IGrj/咼(]?EkijI{YGKqړAhj:ɩ{Xfl;̵ Sib?*usr/man/man3/pcre_get_substring_list.3.gz0100644000000000000000000000101607776057166017450 0ustar rootrootv^?pcre_get_substring_list.3]RMo0 WeV]]a@yH ;P @ ˔A}~('M{{$߭o+xb Fً{pF'0Fl\0önux@mW/MCP MPR!>x0:ȉz]՚Qj?04dJ=R҅^bI킂 }bUw߮ݺ^&~V*[H>(WHAӎTUh)@)Ea䰣c&1WBuQ#ZYJ_ec0$'jXq&>;>,9>_Fv`q?{ׄ!99)Z0@3VL8j4C hrm7զn@+PJKZCglf]"sIh/ hfo0! e~mLm)oWj,Ux]Ry1"gޓq1usr/man/man3/pcre_info.3.gz0100644000000000000000000000045707776057166014501 0ustar rootrootv^?pcre_info.3=OK0^\qsk=l7{Y(HN@lB$Uo3o1Z;u<):Fp;o{eV_v[{a}-GWqBx!]e,τ. >*̓HA6L8`lIy?R96۽O]îͥt]WRlHDz!z0c '%.iO$ !?(`B/們{`M=]A~ܪ2|FJ~C擎usr/man/man3/pcre_maketables.3.gz0100644000000000000000000000063407776057166015653 0ustar rootrootv^?pcre_maketables.3MPMo1W5p!%(94]es 9zc[!P3}> o`m^Aɭt8GUS wL3O{m/dEB>y&5~,)U4z4-؟g bx d_DS}:X0L^6ɠ c04N &bI[ЊQ%؄kTrX=!aJj3g.}S*+7|tqŢ 5RkL-|0AQ%)9~F%.hP{W¹0`"v*pX f(6nՇn 5E!`_զ"qQ(aRusr/man/man3/pcre_study.3.gz0100644000000000000000000000105207776057166014706 0ustar rootrootv^?pcre_study.3eSj1+I]J/M(8{]JPdWTI螤y޼jOBXLfܯPSWz.qZ yi;4^W!뚫܅\ÿ9rih47M%m[iж]M`\}2m >~vو0 O.Em[UZ.N*7hsKdzC ybcϝ( G$ireYQAVNe:p0.!āθD'r/Bq1~ӳg?2`98y 'k ώig{` '!'I`~2 0lZnt|x>'O~."1meNvGXuPI(e7aFISPg&6z,#ċkhRs]K7qHӒT ^n`T4ihr,@dyusr/man/man3/pcreapi.3.gz0100644000000000000000000003210107776057166014147 0ustar rootrootv^?pcreapi.3}sǑWL!W/ ’˱(gTs(f-]ן󱻀h_^Rri;3~o_\/{{qߏ+Wz5llnæruEM\|u}vm/_Pǯ̤덙<ˋjpͼro+*|O78]r9 Lиxۼh,<*7 B̤(pCUզ\.k-p0{y>~>4U&vyU\8{@-dnN(+W6w*&~"iz^pGC 4hfHMF.mԶ/l{]>ymW (&/lsOvfb |)[ե,b[.}m6m1' e@ezۦ,)ᑳ.ң!f0C [ )l)&?Vlfq̋06(:Ät"`]ݸuM_YU;Ġ[-|>h"~[Sagd9ޙlXiŷV2Ep]LS`*:y Έ{HۑǐyUD7/׳K7b ;뼀?Un25a`b`l톶V*xlʪ9q5 t#RR}N)>6[5ǃ0aY0KYubnlMlnjKR5-_ą;bДq=y9{]yȬ7![s官U\llaveRk'F[u;f!a􅖰"l|c8vλ).b"a?a$ci dV gm*+5(Xp|8lR|["(f+{>XO5_5b6'A1a/ V9˕k(r@@eڙ\;<>}pcKgl\,ϪEmKǻM`3)A"~K:mF(g(!L$$ Pؗ`vUβ}U9oY }H*&G2 bȍ`C` X6c& ]8Vi,6"i:d;ygzư]* HU6wAc;d(siqz/ymr D?U6 b{^Ğ5" R@FiU'"X )# "8_nad[,H"Psk!E5nӳW.b%E5Lޮ@M " ̛;xb~uzhO @dMV#K *Zhc5EQh#p=J7!CLX ޕҽB hDv:[iPj" U eN?=v>{}vhz^]^\j<J ÀHL*M%ps0+vOv2T@ EWX^%PL ~HILuIj6~:p0A Fie>!mEZp&רY< s"5V37e v? rG){~~yrjO=gù mػne"FVDnHxz=˳tV:o(ċ q%ߵ-iڋ,tIDۙ W9x9 cx:=߿^0n W_P͓̊5(WP木y53dQdu|[^x%DGGjᤳgk31.5lCf!ϛuC5@h`Ie/acқ|8NP>1$(6u8eM>ơf䊺n2&hQgY`uYqZ?^5 nR6GK't% My" 1(ip؀KR0Ύ0hduנK'ewf;zOJc\,Pah ' ^>]MϖKtD5 `/" S]בgA1Q5$bE1aW8 nic/$&#Q/00ɃoIK`\y -? Pe ܫJ2Nƕ5̀ [@K7'_^>"[kr ^X42F| hlictŪG_z9nb.U#+sDQvxp#`U rxD2mlACSakP,)?!,L^%KE4=S8jx,ٴC-AdǣTY~{׀,'ÅgOYqCۂx6 Z;x_c쓄?{SD+;wA1N%z| qrJeѓ(&5cW&D 7&8ANNa*gY1+Rf$RneW~ -!MPE9`]VQ g p`$Zc˴ pI4fS5z=R3E1Y l~T `|5fV#&}`ߘP(CL?>Qu %lzf^=b>F(>2(SSQƫ'l`A`Td$/sRNr"dc0vד$fPbلSvqyszz Fǫk`^ )m,:ZCDa5A-Α!EVkPG϶=+AUJk_QS1kyxJ=.ykLN9 $G s75TG{T3–z__|wuzM*PU¿R06+t?,QN=_DݹkL4x:PR~u-f̾Kӆ DUP]Mԍˈ0?XrH֡^,v-,:bby) vE:]&@8ֳ`RBH&xTc!z0D95)#ӗUngb7+r-gٷ&% , ǵ(t\wRvbOa$_ޖ3 KnܔmSbǜ𝛿Ӓ4~:O l[,;l +@똌 8jUeΏglb o#A9\ )3rЫN?/G8`aR#?`#,jvilxf#u DHCEJEF~Yroi% 9lکQCC &id`~!n;ޅ0a,Jo\b:Otr:#RBRaJwQx.`qw޹@(CX(ׄ`)$wJQ 0| UNRt:!h,pӥ Op_ĔIzk (CkOG'b2P0&WGt谽&I$?{|ı9G)zFfI!Zmf{Rp5!´ ۲\ĀEԛvl\X3%ۅ4bPY-/#' QVliN]d%LF4I*=2W?^Ɖ5mCD/ې`rBeCAlI.?>Q4+XCkkP_\?F|n|tA`Y]qZž0|M 8x5HGA?THCkh]%*{2@U:jzfmco BSTHKEzST/OOW.b"cvb±ގ8Jg |"O43a͝$xq&GBE!chf ƸYMOvj&%d/d((k4VcAZ>b1tt3ҢplBAn֧5z@nNNIT"i] Hyix{Ɓf"aE^i Xy #jv x;t}Xm',Ez0 9(d%({ P*qȘ(Epb5L h?ɿ%wϼ@R-޳XybzWD]9""9sMC N ;OnNo^`Y F4e 8mOL&cI$n8cai{ERٻc"`8\K8lIK&H0[en2\?qq3b偡a_EP>'T {fNJ]*|n>}s A*#ʆʭy' -$P6G : g/.^c=~vzov[p[uJS](Cs{ -VYpH} \IFT&\߁bS0}LAC[j27Kܑh_S8Rd9w(HYbx(}'%RN.n1O;m]HJєώ"TV|A 񠚶 œZ3;T`ǂq`'*$@vrbg! K6KzC9!G"/v" gg/N0h烙j8'_`Z}yQ8fy[|7HӢ]V1nr;Q7M!_+7IwS $+/LTҘa6mY.[8x( ڐ-2b6JjN& BN_ {;=Emdݑ'9!!3 $3r!8HR73 )M(zAt˧1BeU9?;? މ27R "lYޘFJ=Z2 b^"P$v*!. a)-)sN^>s~|==?=<{IrT*yDN"r,^7h>7dӯf"sY%"T&`43:'̮i;8YJHNbe5˂>Pg?eo.>YZK ď|ut=n5ve ~zz1zC%_hI|{i%fDI8sF#Fɒ@%c­4)`DAF"c4#ѣe4+bI :G$T  q>nf&|ˆqHa[?͢*OGlcwX)j^6#GMy$ЯyR 4cJM%-8Ss¸ ۤ|0KQ%7Me J(aT-H`݃hNFQFKbKpjIF>pzha*] hR,A/]%@!M_Fv}ĩh>mM`Hd#!1 + Vl(Iڈtrfu $>%.9?rC_UW`;oO;U3¿H[oSv矌r(|:LsޖGbB~QޡtU^[I@H)o} ӏZ-878[RbLTD-R@U:L*рpo(h51Zcc2Ϯ/O/^_  Nǡ0 l!^t6%(Ko 8;w(TD`M]{#yMb#40`z> H FzVMNB)d<@^ZO:%l+b:2;X&9Tѥ.aG47$Ɔ%+n &jo{HzJC9i*ŅFY^#رwSi$ 1zow1OIf1Ni0Y&џJGH+4GO_o͈マ|r}#Ki1P0M5Z&/?~܁iOԂ59Q{ybћ(L".!~ӭ#򐬜K) ;Dr`UԤXIyPW-)WCi8c0].u#a'Ep4)3$$@G _5*}~ٯ[dAx |G >)j'@Ch/N5̚Q%4nK^K5~M9YA;/XK Jx>9絆 4W"flpYI)\}O#Vo~^I,Vg<5iOMA @Z7Xjm2I;M'mpH6lGs"` hsC*i:51eMїd #@<ҴQ* JDY|ԔrKw5Xojcb $K4SȣR a:xwDU(Ŏ$$56:]`9itap„%v5n՜qQBpT9PV]p] Sz. !2kZ 9YY|ٗ 6Z,Grhv)ՎhjMB^_Ggqoc)@zz (cg2\ݷ\f$F%M 5k/ҁeZaG )ΧNxec6sTv(}RVŸQ۟Ã}(JW7Ti֛fZFW}^GP .LN;iBA9(3fd+X"/.>{:{jZ$17Vj̸l>lyxR+k'7L.ƙ0g_"RwKvqh"$P~WTe9mq-R#1 IOr n2 c?ࢿ"i&tB J\@[_Qo\} .qLV!_0e<%s QIi5pK"@NN&ҳAA´nԥEyױ{;ub_qεHiTIt1ߐA*]4I #g5#u̜fUznқȹ' .ͿM+hfڑz"s囘fśg0iJ=/4Ʃ`_1еEU=ǧ3q/Z21*:t$bRbJt!RAZ-gT|ڥM D!Ȼ\z;g^,%E2gy]Dxg_9^.8b{8@C,($ 0i/9:{ 461>gAX]zK :5lr[GzK3+SF48BR*[JZ@k ^\:QDJmiiFfsA&! eqj#3|iHo87 NQ!K i+"H EIQ[DZ˅<9/Kz[ VSgBk)I5 KGco$mͷ[}C˂ =֐qxݮ}4OQ{wED"(6 Z%e (&~uV?&cs҆F n'%Y^'S1}ۗqOFE߅Q冥l`oc܏z T`P%΋jBA[IwLXB\E(W3[ꋄTh2f(VI0Ɋ0#Tsza0KKuL+%NdtRI=GkgQ8W:w睼+Wxo$ 0䄅"X2x)3^ {` OCI7jP+C@rj y7?̜jn!IkI/}6LT|8St1-~y'ht"PR=;I*EjPrAU__Fl>7>&r#߳jp];:07HNZ^!'X"&J%Ώ/P_ӃhA!ngRZʕy|k"R^TXyQMYrH "+d6hg QԬ{_ᥳʱҰHL76D!iZzgnIʬxULoTJ֌9[|^WH8y`˷ I5rǖnJ/|&6~SzxMq8!LX߿g {R{^fM%OzG&`he7rf+pW:*֒u=CǣO:=_7QY+}]2_,dQs1ަϝ|cs)&ՙVHd|5QHNogt"aQd[Dm Có=k4H bn2fԭ$>9 Zˢ_m Uڿ_. pS`b@H^_pqPSZFcJӒ:=; qkB,p3LgK.-zA{Wn>\Lz2eҥӗWoq$rcxs[zxIWxHS9IJe.6$ճ 8ٶ(LNn4a3n>k_ گ_?^a:GϡwÂqU^Zu)}Ѐh-I}5Òf;aB7TRPf1EI׍Sň]^ j/U(hE?SgCkH5$$IS(n|$`g Ǜ+x7,\XGe=̛bD^=B`c8l}Q*²׉av2EڗfBϭ?z/^qJ qZY*s?l=iqdV%+H?kIAy쇼 :6IY (XϿ*3wñ yOIq3 !l?šX!EރM K[.m*k 4RGc uv#,h1fz[.ʈ\fhK$9b4Qw+Rd$M 7nVKPP8dK_i΂8*B>xwiOoI1m+ScoPmW^ v 1H{9-nhBZɻTS67nTm?$pե5XM8W ML mIpi\<.*CHT~m[| !0I1_}HۯݱcW[IKg/:ئ>%=8!\9C+m@1=06ղ`!eֻ⦯]rckseޛVAА*LKjOp7%cW`")b,YBP휌H~71y~RzcvR \|!rlyJrS! uV%-œO y@OpO\B2ԇg=+JAWFWK㵶Z$z rXEΙMOtMǐ!6M㮐Tq'AP\5q;9SMu@HorIHG<7#f~EGCǯ87h@t=6eKL-t(%|=VIj}e[\z>[r#b Qߗ{"zihq^9FlD)=|Hz'NK,әӷUFm/$oh5Fj7-"u@ VyNGȮFfÇdy1S"'axb#;|jڰ(Ķ@@2#:j;1Ä|n$g vZ׀qrk~YQ SyG$wwrǘ W(_lΙ68S6&o?QL:K`KlC 6 ebqFAX|ȥ8)IY뗆eOoWJqF_m O9?Ut}F+0S( 6,\Tu=2瘻`Gx{G_=GG}]Ap]IUl\usr/man/man3/pcrebuild.3.gz0100644000000000000000000000363107776057166014503 0ustar rootrootv^?pcrebuild.3Wr۶}WўUnov ;J[rt HhYH9{كZ兘}׳s y-Jt*mo:k}^|˛NL=އNw&ʕ}(+Jo6:ȸu(+kbmӆq,U+7Zmuu%; Zg+ؙ"4VWST^Kef"Cǟ{0i"Xg}Y6[gjq)wt)yҗQ4MApHVG 3Dh8+_qwoKW "RœJ<mKLU2o?fDeZ@}KI )ߍ1Ȣi AZG8L1ט~炖jFofoV/Ee`\#vGN.M}N[=ҵmLHqԥca2&bJb1,0 Ca"C &XKTKiB?ւU}&L&xNhBo@; ⭼Y]㰧UF6]|dl"hepHUUT!ߢ[!G4ojn|Sܐ-*9+0=IH9%&zxwA C)8:Zv};`MkJ@WzWnS꽺oϫsly) _Xc^ o еwӳghɯob/B<pQ7a*Ar Nr!OJQ[R_c{3Jyv0(e& b\Hc=ta XShO? /L(>Vrv^ޭgŕ\..Wbtd5hr`Y2q<8AC0)% x3X8uYiP8U KJQ:rL*!6-~g͕}< 5AC λ~KKM kUjy~C g*cH$.EOw~H$".kjSj~ws?jCJf2L%AueAXO8]>mlx*dIin܏x4?83=ő4;*Y@rhv`C =T'T~rҏ:q!UMs< J`dH M~K*h,dI8 #_1-8w?ѿȔOP%1>l FXF"ƮpbL%z_}br_,ÖJUɡsA;kHjT|uwy9R)5M(B5tܼ9v>CZ.i# G>arbW%2ܚ}UTFvT%0u!! "wӟ!Y!^(nFdHF3(Bn*vJh>^AN .쾔;3͔MwJu /:|HN{gdM%CZ%)0,*sU6\GL,Cy@c0z #[U(rQ A ~X}g¤F3eslձ,~`>)D05%)C Pk425mJyX Q+Pm|*mgY^8i喑7k ɲ 093x9eN4Fm"jf+b EW]GI0s0ŢF@8it"liCA| y#dcXAYPpZ`]C,z slj97\+T 1^#$=w\̩(NwaD=3k EHvnۻ+bJ's9f>w#wjB)^m<؟57K8?&\{1Hn5KALY;X: ʱ|MDs 0r9q\(/<Ѱ]8&ܦ4S Q!ܹDd1hjֶǬWζQ>ˋ/7G#e,S/ݞb-µjJ*2^ʙ9hn]ɈE y!wBC(^bPԐzj*u_K E ! v5WNn 3z_~vtF5+Rusr/man/man3/pcrecompat.3.gz0100644000000000000000000000363207776057166014670 0ustar rootrootv^?pcrecompat.3Wao7'8 U7M?\ε&G)6]xܐ\J7CJr} 73oތg7r.dOsb/꣸//[f7EiQ&R\y6JS6(NJq ~*{L<3_R G6p"X0ieUQcumU@&J+5^n,^0VFf*.?[eF<_[ۉF7^lZM70E1&!SJd9IGr4f|v8%$A7#&gLsڬrPMdauIpǃz14++lg*hkӻ۪ 8}Q]~O5 ӅŃtZ^T6P8K 萫"1`Ե'N.m(1k1DJXD'BW)QX$a o[oDt[M9Riy n+(pW!e%u yH5bd kGu&FHuDw ERR}??hBi~vǎC$~U=WG_l_k1eX~C!Pz fBHwt߽X+cDzDڊH8xȔʬQb*] G\bCrr ہaa_?l1N6!Fg; i*<*eHp:,@&M{% 8-XQF[idd/ AP(d'񕙘8ZrɌ*NCiHPX>GIJY&Nͨ >i%Ce^=mQ'JpL.A0Y޻z:|X:<.c /SxHFAM *o\\EjV&lmY =~{aKDŽlMd\# سD>@ RM,EΆFy"7Ok#j^|;;;j6i-SOOV24}D3rx<1(%U]ٝB4jUǐ, l Lx8MB60oA]kE{vd=1zjNzZҧ`|h>Ž\38.٩?(hѲq H6ԁzv|5W{gIv)!{][JOވ ''c?wٙm靸5pp Cɝ.ɕ?aV-usr/man/man3/pcrepattern.3.gz0100644000000000000000000004315107776057166015062 0ustar rootrootv^?pcrepattern.3}i{ȱ& 8=gƾ,o8e$(!&%vWό-XzɳÓ䶛<9x|YV-fj6t%UvYU]WY]eQ=to$G}vrtzzIѩTp]vgYRo&}?7uY5NeyJW L,V4['t9mȀGӆ8hW@2pnכƚ.iϏAiw rD.- l|t $2dOcqq{)~cY*mx>I)L>#5gI`<1ZS:Yȯ,bNg|}#Uɟ_#և[|џYF.kD#~uGI7.>?[,3<@)O/ BE/~֠66\WyMUZ7Vktʤ0dY7(vo:WЙts4\_fE̳>8+%+} |Ԙn( `C(bZ? *5Aj0B$ ;& >Ϟ7*NG֍at\WU4~*N dg=pYNYrcI$6Ǖ.l $7 ρltE@eW;Z~ic\WK8H#@:AEk] ktBȴgV92^i6x0K[%*9ADAnnƐ5>>Ċ(ڸ`iGs6n‘3TÍCeH?pNLr8iSǩiXgF"SW=>6[Yolיl!\%EcM{=ơ}[qAk9/qG_ye@De?>T<`[1;pA'gKĒIk^XQ@~ldD3[}_`/\%ӱ_]19k7t^f7>֞RΑWXț{)V3-0s\_f 1d%ßFd~x?܂O# 9hɺfȌ^MI+…լ}^h/P[ciNe#Ƹt֊sآϕYr.='F,BH%pt3lJ hKpwJYV5)Əs;A c4EBfʧtJ1ON ]4CLjfE*=s/4 A1 L(vFEaWA2fY#D<N']t?$>h?2ѐL44;!YK7QNˏP%Yq џ*'u 'Ҫ3گ|j&UR 'I $e|`uX,FJӎHsqaƨP s8zG$<# wj̜E%x>>[d&s%fI`_Tf#"3Qs&" H|FcOJ=b!,m~-?@\7d0 G&!p H Wa@aTAc:K1Qu8v r\kZ•O6R cD&e#bq0kIB.\Mx#/,C!ʏ=VwV`Gӳϒ᳣ƠDAK6D**-/' $L5G}z,׳9iGBxZ"0TGeQ"U:;x(fLc`RZ-^Mv' {83Ȥ/ ^M[(NST!!=>8;oAr <:JKԇ8'CJ?czC,Mƴ@zj8k؏&BpTVD \ͩїƙo"B vž+LLXX٣t@$IBB}%H c1Y.S4ha4 ,7`vo<}>!}M5 +t|A/NuBF~~ürp?Gg!q"8]-^Rlf )xZMׅP5vF{M^U5Mb[[?Vs5j|Ђm\A8""ڷ&F8o Cj-gz3X"t\i[ `,ߦ^0kL|ъ>P[gln ] wPL-}$b B]3;&T{RiW5+q)hquŻ@DT3].K_( lS)Լc. y<)IG%HJ_uA4G[dGT6 -Cc12qCQnj@U@>q+ zQgtl~Ooa^W.8rYQP ’lݢT78 aanQmRQKIII-΂BM8~a S{&q7=Vt\ Bott|KQcB=b14:,G֛ڽ&brBv&AH6rj)hjΨ1px譮o7Yٴ/.3w``b^ >إ `$:ܛK*qxe2y)xt'C|p2 b ~{<|>ɏ7f?ԗVnVЪzw^Ӯyedmϊ"3 F̈|w.'h^:٥ |ð>^'Gd5(6UUV>SٺA=X|k'ު[rtrv|x(oAA DvC޺Tۖ);r oPoKP䊰 sl;;74vƇ Rk$b6(Ih몜B$}Ck]ɈJf="YLEi7˲W}\1o@#qs*2Μֻ9SB9~ ΰr#ѣq%2f}6 VfTlj d 2{bCD}h!zCNeZ+q3 Qu-^qMb6/NUbk1&,IVQY3% QŒgw蕫)RS~LOesW8νHY<8Z ƕPӬˌx]<쏮xd G#JNN q|o8 Ea=^u-M\f44UFJvbqqEFْ w@ޅbs,KRD1m R:$\},ғPPt$Zl(& e@\,Jƀ,P=RbG{=ř)rNs_'A H+@hfJNgLB{Zz"sbZ2d-+nQm>Eʸp<Uv/O͏9ZgNw6 e  bDTLEcY9|DYcw?ݛHgRU T*EVtE*]2e\SRؗ6ť#/[hd]~Ā] NV&z]?q/S\@0G5$_*iT ocƵoLCN#2r2w?$mDCs .Nﾻ]Ȃ;ٺD~-U\ƥ$Of3/u&juB9Jrp}9KaEv]MP CJ{03dpO8Td>o1Tj j 6CzЫSEo5ո8B)(&֘ \DD.BO` \icGDJ9\s(G#Kz%c f+vd@*ҕء\zN( tlijx/莾;LF#5Z0M'N iAlh#ϟAJ[oaxZ8C5Lb 3PYi-DɄBnk=!8(0}Ȝ C B!=;:;F/ߥ[rzZVg9jPU[H*-tʵwAaOv봇H:hMeYĈUv1 Vl#in#t]JleX"kep{{Ұ*,Tmh)2ğ!exrJTz`J -~{R6E1qXm&R^޽5q<{*;Mwń{}Rg=p0-sB3`Yn$gGP5<] 6W)dQXSċo͒9Mi+|j'sE?JD*- W-q,lKGO2  OK,ڵ?7Gb$ G\I-J$' ʢU Vo} ݇ETc QJ1̆1)u@L]j6Pҿyu&: W Y,v 2$t[\n$>ʲOcbgL88λ"6sCvZΑt}~O_uGF 6NW&E0ԻP7.yQv")bQ S7yD}Lݙ>qnV H"6XjbWfɘ* 3tDoX 7oǚڴJi3)d`%p>pܢ_o/A Bi u Z <wZlxSII ,IgWԑ/Aj'c*N9rWެ6ZcbV섆,*'JPьv!jG=t7򋍌 pcʩZiUGE_x~OK䛍`f}mZ6v˵u9fC}4 ј'7Fn3X_Noo݆ AHC%P76G)0:e==ZbLű)YC5V#zi`?Y]=Z|^19\$c zBuBIHsO'L :N\$Y$ FJY;aa8&Bʤ=Tղo`N>F;<@|_???xrv$^PQ.ZϡƵ1G=diTb#܏h}BNlsݲ*pji8ߌf5Ҕ.=׶NNCzE%]nJӼʠ%_e1~nnj|t<C^^)DX,Rќ-EYJPpsZl@phiZiӫP da+M6{hҵkƆڲ+.43bY7r[)_`H_S]q}/$4%:ՠ S"=wwXT`m?D5iYow`NⱫ-%t5,OQtAE=eW6kg띕6aTh[HԢ0hb-{wpYEB]Qٙ+$rF5tx`.ˣ&(7N+,!iЊ@rC4((_fІrM[*cTj4͹rD@4c;D%XvENaya %jVHmĖ{|LEu VGFt?[+A41WxF Ĵb-#_J |__(C ŚHsY#|ɖD>mG>͍&t֚Δ1 -:ӳ@U6D]Pot / !R?Bؑ*.3c21y$A"ߕ< 5aa[<wzMJE^=to ]!zB#ҪM MGh9iDguԟ.J!2&R*;/I:BˡգL}W^_OvZ~+|egѺK;[('p (ۧHU =vW~)lLS8-.sB)ɐC \EUw`⵰/( g]LPcK4ՃS]>.Sa&KR]ٖz;ojcg:y9xiB9du|*γsZ)Dz0 BȻ1ZŃM 1NM^DAI#5orVB^l2)B!E]CZ1:~|ar᭒&8K=~c_MB#aəR9Uvtl9BA|!HI;A9~I;_9ok"Ő "PX?&a5?J*68eǟh.CN"Zcc$D,V\\x|N=~Jmԗ|Mׅwz#!bMG0"Y)6N 98ὯWE˜_g/-WcVb.)xŚ\o0zUMj3*bЕ:|5Jjہ u%AT#qt o x+x$GZ9'jm'!*t4ԟqqPЮi,c4LAàV!(Y׷Xˮe8ʆMSXTX- 5Ӓ8 7%)7/!/3jTA)QsC[*OHsQok_bK^ޗ< 4RkynNTR"`oW8؅3}EϜq̤\3|9&\8I鼼}aR߃Ny8kBi!B=^ܶ H[L\`!$&?HML.dh#=PZCt80FDbfi=,V&Lv'+ 16Pxhj^K>c]&`Ԕlb3oTHg) c&6h\zZe^J0pU^e)ʂ:>X DjFISizywcGPGb>-ܪ[M+sc24#&7-[ٸϴõ&>T\:{/n').ȇZZ`NεA;Rl` yݛOI\8=۠zcԗꉲw (zrCfjɍOd]h{>׾ ;DɆUSS#Jۄ؜ _t/$yJ࣋ԧƤtڃ1vrdd_sV:k"E_ݝ WG+Ar;\k2`8BxϚ9a9=gH* WtߘKSY``! `+Va#wJ덼B`w@(LlQgVN #,J8r,DKa42q͞TOY>(ٹc}l)PD1͏Ϧ=]Zf]qna&)98%p(meHw1.B_tlw&9cʰCcD=`\.溇Eg5/]ak (RҭFJ}bhb؋`Ы' #e9stxOYsj5(ySV(3{od=Ruc|'z;9f+a.(vr-M&k~çOPGޅ-NB6BT[DQy>D}LƂb#2axw' J'D.im}&=Ժ tnT]bF+ mVO|(e^ɝ᛼5̽D?2&bdkk_R=|=bęy>Y-WY Eb|=jO FS68Z)*퍪PJMoWYŎ{ҡAm!CiR 2ImeYV-W6la2"/_G%z`1 rz*G@d 8tԶ$J; yC\δ%,,Oe^sHs;4+0H)Rgm&r,n4O zBJ!K v^?*MVIE䁙c˽VbH:ltрgƔ§f߶rKcpY4XHk"b `T(Tf )r sÀ9{/zήIr_*8QD8cRoq :{e\V,|iAX`ndv9cq7y,;}ѺHn itݫ/Tq~wOjђXv@p¦Z]jc4?;ƑIoNewyl?9WULVmަuζ4E {i͉O"›Cԫin>>~|Ĵ?3_>@v/L$Ts[x9I خ$, ż;@E7-H|Ze6v֯]0`{*"ݮ']F;FKNCҸ$Ձ|J%)2htζD5BNbVgCظ6/hPD&/d-KfÒ~MA3=K,/E0S4_TW%F6v\e~DeץNNi)=h,C}|6Ȭ}ZHiƖ}%.:ƻTK@E j% o ؓ#_UQ޻iAzǷ?3/& |Aa0s;OuZ۵ߋE@IuBдbfHDrNp %["+9j`YxWrT1lN/[i{-'SڀfA`b.QѺjZ&x(oQGm#u 1JF |@o6=>ὓѧf#= DtD-)}ܕJztjtlC^fR Gw}NdskG[c_gdZFFj[ъ͆.;<הATkS]{5b=:j |QwP2XN!(Obg{cK5#3V|guP}!',S~T*ْzM0cid Zj{=Khs[ #CȑJQ_i<1]Bh[~vw]'#;E鰵u28d)>7=I,a' P{k*F`QmVˇݝqV$e4(ktgKlSHl~fĴ'JFQooOҺ/b,$< 9xZfiE=qI93EF-B b!%>ib#@ٳ,c1IBkI}.nbkFjJA2R$.$5LT2N>roQd'kt3IN([HSvdfaU>˷SƋ㥋yE+|An$}'Ư^{,ܣiB<㉹ҊS@F!Ye-$|( KkSzMt8qB>kBkLj`(߳>QXa:1#Y.*cs2Ey(tN`B־N)/-c6&U_3h)yD/98_O>?;~bRv7H#K(1} UM#ޣ5 ȴ'Qʄ pi `k65!HUc_32A|[U$M$?HjXҨ%VxIujmi 5,ZhZ6V^Tq.@MMJ!oj4'cvM6Ih bt?A`HOhH68-$B AǗvպ]GןaL1&,ʏ&kƗ"㧨i̞ۈ1)Yy*GV55Q0KP*Ҿ u ѬL6" ``yoDhUοc nGh_lsInNfj͛dZJo(ySJgiϱV"usr/man/man3/pcreperform.3.gz0100644000000000000000000000261507776057166015057 0ustar rootrootv^?pcreperform.3mV]oF|_KD@9REQŊ\JWJM+RG-yHNtQ/g?]E/u]UFq& ` m_&J[xq_ҹ6(uv>ohz$JKėI A4K+n4,Ψn۷V?<`PvSAxx P&{  QV; 0zr$s:gjIN$.7AF*1q#>"7k @VN-򫃔hYa.1k}?b7T@x6M hM :$u04mN#^_µ>|(%]`>|fy#" FO5>|skk0Bx :*;~(ʳ -Av|Xl24(aߌ(Gbg`@4Ґb*Q~=fr2E]Xnj)Fo*~NK/+}+`c3iZJ^g)N m!6-lHOi|ϱ rҲ#6Y])w%ˀͦ!A^\ϛ$fND^wH c~zĹkhefGG*3lci4ЭD=jykqJuk>hFz6,邞/łΌ6>f4f55`(iNۃeA=|z(E' ї'd_UJfkb7JDq#]Q8 v6ta Z篌6`':8@>z3R ;h;inXP nRPָį+ bn 1!W[q-:Xt+(HuEnM;A^jStf?[c[Sn[IauJC&U`JvNf ۛlOJ5NlU XۅAh6{]ڎ{4M=z`-Y:%0Q*z5W)=u^hАm d_"lѯ7zڣݘ|kܭP_ usr/man/man3/pcreposix.3.gz0100644000000000000000000000572407776057166014553 0ustar rootrootv^?pcreposix.3Yo7N^ 6Eq'MkP+fw%wm+ ݕZgK Ǜ7T:g|)幼 ~*+Os[55RK][7-_//r// 1u^v-nrCFdNdkGLݒl V}q-b"shjen~V^5͋Rm=^>(:]J|L}Ûԕj^4ŏ?MMMQujr#<6[];S[zĄ;k6$pZ Vs̖gJd΋7b3^zJ[Ȣ2B6ޙR\8ɃNt{LQՙ\jM ED/fߊkJ D]VRYXuP;Djcy3*;fch*E2^gӣk;TAwilw].2We)d#W7,HPcj=:V |ՆRO7̓{Ҭr{iZB"Ddވy*ZqOP+N^/MC Q<$m2Z _C"z o-[kivUZqt(X`"ׅ)3USjJ M۝J2b ##u-64՛=/o^*M}wk+uQ輝uעp\Snl$^-R l2";J}@J uחT^(8)!<'sHqQI:.YQcx8dwF~TH)14tx4m "65Ү5O}!wo ''B- i߭ZaS·cOKui3y2X,'*@:!R*(=Y*[t%7;U/}&`8bH BnYa*9ȉ薐(J$wT8OQkۆȺ֨R;ɩnGh*#. 98a*X'je<1Nrw"i'N{osmdelPCCLXKTi",-=pkJ\5$|CiXB8CU VhHY)\jkN/N^Pyut~'e=Ş3c@¸E]_\^\Sy=]fqB}t9oZ6z4,r"^WP?* [vS*6)n.]1pak,[Dxz4ľO. Qֲֶk[1J,=$pʇ#r\"@/u:5"z:@aaK TYt9 nlL]-2{`4,/GM$Yy5i4rE5Wؽ3ö\|LXZy|#zͺY)SP(/(jv[c @_RqsG {d-{>S' ^{77@o{,$_x&Xw81v2P<:̣TЄb MabGgfӉDk qYQmj,ԓPͰǟO<rCv6*Jbʐ@42t֧n P!ܡ]9sٔ;;#U).z6Jupq]H} 9潢כP4ĝy *Wv`)I[obKy"jFڐWjzyiUE@=Qte~uÓ}D4Ķ)?'Tq`"\ !s tƓ;>xOo9[~[3/}A9 6@?C-\7m?pt '>4HFfkp*<;5Pi9w@yZk2ZW(Oi4ˈ14)"1*Q]DmvXO{1܆Ԗک&G#͍ĉx4&zcꃫILzwO@ A:C-vfWSls=V0sbB0(I" '8LF~·RXxBᡟǜCB/:%Ux$؆9Uk;f^ɘqlO">Ukf`$ERv"1r 7u),wXCv9&4EB8N'A|HpT(L(328թu@*''xzMJH]4-]pq(~桟R}[H*1 s }z7V;UEgԑlJׅ.Wه{ il_'& ҜE1)2ǿ+ '/yA$G Xn]Z}sƱ8ա `EzN l#I7CʐLEz7%]s1,Zk_ N@3ώZ ^ E兹٬xNL +wIH 7\P/#FI` 9k{#Zdґ\ߠ"]ԆIupf[ToǘL?鿗q[Hvdo2py%;zUC[yj/X6n jef:e!?ִ8L; cODs^]/Lj^EQZD|g@0Bt8Dn%d'kh\"oW8DYT1̛䟓`"3\C˦e/JIa̍˴,;WZ> ĥLt=8qi5!ΫFuE"{