SkillAgentSearch skills...

Pcre

This is a clone of an SVN repository at svn://vcs.exim.org/pcre/code/trunk. It had been cloned by http://svn2github.com/ , but the service was since closed. Please read a closing note on my blog post: http://piotr.gabryjeluk.pl/blog:closing-svn2github . If you want to continue synchronizing this repo, look at https://github.com/gabrys/svn2github

Install / Use

/learn @svn2github/Pcre
About this skill

Quality Score

0/100

Supported Platforms

Universal

README

README file for PCRE (Perl-compatible regular expression library)

NOTE: This set of files relates to PCRE releases that use the original API, with library names libpcre, libpcre16, and libpcre32. January 2015 saw the first release of a new API, known as PCRE2, with release numbers starting at 10.00 and library names libpcre2-8, libpcre2-16, and libpcre2-32. The old libraries (now called PCRE1) are still being maintained for bug fixes, but there will be no new development. New projects are advised to use the new PCRE2 libraries.

The latest release of PCRE1 is always available in three alternative formats from:

ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-xxx.tar.gz ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-xxx.tar.bz2 ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-xxx.zip

There is a mailing list for discussion about the development of PCRE at pcre-dev@exim.org. You can access the archives and subscribe or manage your subscription here:

https://lists.exim.org/mailman/listinfo/pcre-dev

Please read the NEWS file if you are upgrading from a previous release. The contents of this README file are:

The PCRE APIs Documentation for PCRE Contributions by users of PCRE Building PCRE on non-Unix-like systems Building PCRE without using autotools Building PCRE using autotools Retrieving configuration information Shared libraries Cross-compiling using autotools Using HP's ANSI C++ compiler (aCC) Compiling in Tru64 using native compilers Using Sun's compilers for Solaris Using PCRE from MySQL Making new tarballs Testing PCRE Character tables File manifest

The PCRE APIs

PCRE is written in C, and it has its own API. There are three sets of functions, one for the 8-bit library, which processes strings of bytes, one for the 16-bit library, which processes strings of 16-bit values, and one for the 32-bit library, which processes strings of 32-bit values. The distribution also includes a set of C++ wrapper functions (see the pcrecpp man page for details), courtesy of Google Inc., which can be used to call the 8-bit PCRE library from C++. Other C++ wrappers have been created from time to time. See, for example: https://github.com/YasserAsmi/regexp, which aims to be simple and similar in style to the C API.

The distribution also contains a set of C wrapper functions (again, just for the 8-bit library) that are based on the POSIX regular expression API (see the pcreposix man page). These end up in the library called libpcreposix. Note that this just provides a POSIX calling interface to PCRE; the regular expressions themselves still follow Perl syntax and semantics. The POSIX API is restricted, and does not give full access to all of PCRE's facilities.

The header file for the POSIX-style functions is called pcreposix.h. The official POSIX name is regex.h, but I did not want to risk possible problems with existing files of that name by distributing it that way. To use PCRE with an existing program that uses the POSIX API, pcreposix.h will have to be renamed or pointed at by a link.

If you are using the POSIX interface to PCRE and there is already a POSIX regex library installed on your system, as well as worrying about the regex.h header file (as mentioned above), you must also take care when linking programs to ensure that they link with PCRE's libpcreposix library. Otherwise they may pick up the POSIX functions of the same name from the other library.

One way of avoiding this confusion is to compile PCRE with the addition of -Dregcomp=PCREregcomp (and similarly for the other POSIX functions) to the compiler flags (CFLAGS if you are using "configure" -- see below). This has the effect of renaming the functions so that the names no longer clash. Of course, you have to do the same thing for your applications, or write them using the new names.

Documentation for PCRE

If you install PCRE in the normal way on a Unix-like system, you will end up with a set of man pages whose names all start with "pcre". The one that is just called "pcre" lists all the others. In addition to these man pages, the PCRE documentation is supplied in two other forms:

  1. There are files called doc/pcre.txt, doc/pcregrep.txt, and doc/pcretest.txt in the source distribution. The first of these is a concatenation of the text forms of all the section 3 man pages except the listing of pcredemo.c and those that summarize individual functions. The other two are the text forms of the section 1 man pages for the pcregrep and pcretest commands. These text forms are provided for ease of scanning with text editors or similar tools. They are installed in <prefix>/share/doc/pcre, where <prefix> is the installation prefix (defaulting to /usr/local).

  2. A set of files containing all the documentation in HTML form, hyperlinked in various ways, and rooted in a file called index.html, is distributed in doc/html and installed in <prefix>/share/doc/pcre/html.

Users of PCRE have contributed files containing the documentation for various releases in CHM format. These can be found in the Contrib directory of the FTP site (see next section).

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

There is a README file giving brief descriptions of what they are. Some are complete in themselves; others are pointers to URLs containing relevant files. Some of this material is likely to be well out-of-date. Several of the earlier contributions provided support for compiling PCRE on various flavours of Windows (I myself do not use Windows). Nowadays there is more Windows support in the standard distribution, so these contibutions have been archived.

A PCRE user maintains downloadable Windows binaries of the pcregrep and pcretest programs here:

http://www.rexegg.com/pcregrep-pcretest.html

Building PCRE on non-Unix-like systems

For a non-Unix-like system, please read the comments in the file NON-AUTOTOOLS-BUILD, though if your system supports the use of "configure" and "make" you may be able to build PCRE using autotools in the same way as for many Unix-like systems.

PCRE can also be configured using the GUI facility provided by CMake's cmake-gui command. This creates Makefiles, solution files, etc. The file NON-AUTOTOOLS-BUILD has information about CMake.

PCRE has been compiled on many different operating systems. It should be straightforward to build PCRE on any system that has a Standard C compiler and library, because it uses only Standard C functions.

Building PCRE without using autotools

The use of autotools (in particular, libtool) is problematic in some environments, even some that are Unix or Unix-like. See the NON-AUTOTOOLS-BUILD file for ways of building PCRE without using autotools.

Building PCRE using autotools

If you are using HP's ANSI C++ compiler (aCC), please see the special note in the section entitled "Using HP's ANSI C++ compiler (aCC)" below.

The following instructions assume the use of the widely used "configure; make; make install" (autotools) process.

To build PCRE on system that supports autotools, 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 the file INSTALL.

Most commonly, people build PCRE within its own distribution directory, and in this case, on many systems, just running "./configure" is sufficient. However, the usual methods of changing standard defaults are available. For example:

CFLAGS='-O2 -Wall' ./configure --prefix=/opt/local

This command 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

PCRE is written in C and is normally compiled as a C library. However, it is possible to build it as a C++ library, though the provided building apparatus does not have any features to support this.

There are some optional features that can be included or omitted from the PCRE library. They are also documented in the pcrebuild man page.

. By default, both shared and static libraries are built. You can change this by adding one of these options to the "configure" command:

--disable-shared --disable-static

(See also "Shared libraries on Unix-like systems" below.)

. By default, only the 8-bit library is built. If you add --enable-pcre16 to the "configure" command, the 16-bit library is also built. If you add --enable-pcre32 to the "configure" command, the 32-bit library is also built. If you want only the 16-bit or 32-bit library, use --disable-pcre8 to disable building the 8-bit library.

. If you are building the 8-bit library and want to suppress the building of the C++ wrapper library, you can add --disable-cpp to the "configure" command. Otherwise, when "configure" is run without --disable-pcre8, it will try to find a C++ compiler and C++ header files, and if it succeeds, it will try to build the C++ wrapper.

. If you want to include support for just-in-time compiling, which can give large performance improvements on certain platforms, add --enable-jit to the "configure" co

View on GitHub
GitHub Stars13
CategoryDevelopment
Updated4y ago
Forks18

Languages

C

Security Score

60/100

Audited on Jan 27, 2022

No findings