(1) [D] Then documentation should be reviewed. Try to find the word POSIX in the dokuwiki search - it works.

Agent version 1.9.8 (trunk) tested just for case (especially for windows because it could be special case).

A key eventlog[Test,,,,"^[2-5]+8$"] sends event records with eventids 238, 48, but filtered out 49, 368
A key eventlog[Test,te?t] sends event records with messages tt, tet, but filtered out "teet"

So agent uses POSIX extended regexp too.
For now in all places in documentation where POSIX mentioned (for server, agent), the word "extended" will be added with the hyperlink to http://en.wikipedia.org/wiki/Regular_expression#POSIX_Extended_Regular_Expressions

An useful link - http://www.regular-expressions.info/refflavors.html

Related issue ZBX-4625 (possibility to switch to PCRE).

In my opinion PCRE would be great to have everywhere. It is extremely flexible and used in most products. POSIX ERE has a lot of limitations which are solved by PCRE.

ZBX-8451 talks about different newline handling

Shouldn't the agent also use PCRE, so that regex items have consistent behavior to triggers?

Note, my use case in ZBXNEXT-2537 involved regex behavior in the logrt item, so if the regex is interpreted agent-side in active checks then ZBXNEXT-2537, at least, invokes agent changes, and the Agent component should be added to this issue if ZBXNEXT-2537 is actually a dupe of this issue.

So, which C library could be applicable?
PCRE should be out of the race since it's distributed under the terms of the "BSD" licence.

Sorry, my fault! I was wrong. PCRE is using the Modified BSD license.

correct, agent component added to the issue

I could suggest to use command line to test POSIX ERE expressions:

Similar to zabbix frontend behavior, should not be used in zabbix:

# echo "8000000" | grep -P '^(7[5-9]\d{5}|8\d{6}|9[0-4]\d{5})$'
8000000

Zabbix daemons behavior, should be used in zabbix this way:

# echo "8000000" | grep -E '^(7[5-9][[:digit:]]{5}|8[[:digit:]]{6}|9[0-4][[:digit:]]{5})$'
8000000

I see two parts in this problem.

People like PCRE and want to see them in Zabbix

Unfortunately, PCRE can't be considered as a drop-in replacement for POSIX ERE for a number of reasons:

• manual configuration upgrade would be intolerably difficult;
• automatic upgrade would involve regexp parsing which is non-trivial and will not cover 100% of cases (because regexps can be stored inside a macro or even split into several macros for key and function parameters);
• backward compatibility with older agents will be broken;
• server and agent would need one more library without which they would loose significant portion of their functionality.

With all that in mind PCRE support can only be implemented as a supplement to POSIX ERE. This has some complications too, including growing number of parameters for items, trigger functions and LLD filters specifying regexp type.

Global regexp testing in the frontend must be consistent with their implementation in the backend

User-friendly but very difficult from implementation perspective solution is to write POSIX ERE validator/tester in pure PHP. Alternative solution is to delegate regexp testing to Zabbix server and/or custom PHP extension using server-side C code. By default (without running server or extension) global regexp testing form will not work. Third option is to rely on grep -E.

How about making it configurable globally in Zabbix server configuration (propagated to proxies and agents) or an option at compile time?

Sorry, okkuv9xh, I don't get you. Making what configurable?

Well, backward compatibility is important - but imho it's not worth to insist on it, when this is causing respectively keeping or even increasing inconsistency.

So, when the aim is to use PCRE consistently an a server/proxy/agent implementation of PCRE is expected to break existing regular expressions, then why not implementing the necessary PCRE functions in addition to the middle/backend components and making it configurable which to apply. That's to say, either use POSIX ERE, or use PCRE - where the former should be the default. After a couple of releases and clear warnings, the default could be switched to PCRE.

I see that all discussion is about POSIX ERE and PCRE, but there are plenty more fish in the ocean. Let me throw some stuff into the fan: https://en.wikipedia.org/wiki/Comparison_of_regular_expression_engines

IMO regular expression engines are for developers and should not be exposed to users. We have multi-language product with very generous backwards compatibility promises, providing consistency across components is a tough call in itself and nearly impossible if users can access low-level mechanisms inside the product or even behind it. We don't allow to write SQL queries in search fields, do we? We don't allow users to plug in printf() format string of their choice, do we? (Both are considered critical security issues, actually.)

Good argument to close as Won't fix, Gleb.

Won't Fix is for quitters

Generally, I would agree with Gleb, but as far as users concerns, if regular expression works in "Regular Expression Builder", it shall work the same way in the fronted. And as of now, this is not the case. So, something gotta be done:

1. Use same regex on backend as on fronted;
2. Use the same regex on fronted as on backend;
3. Add a note in the documentation stating that due to that differences, something sometimes doesn't work.

Good point, Vladimir. At least we should document it.

Dear gandalf, I'm glad to hear from you!

1. Very difficult and no smooth upgrade path, because of heterogeneous "backend": there are server/proxies and agents, potentially of different versions (and we can do nothing about 1.8, 2.0, 2.2, ... agents, obviously). Managing a fleet of agents which would use different regexps would be even worse than "regex on agents does not work as it worked in frontend test form".
2. This is what I actually proposed in a comment above that you don't see. Still regressions as people may have used PCRE features, but luckily frontend is homogeneous and there are very few places where regexps are supported.
3. I think, fully documenting all the details is not plausible. Take, for example, macro functions. They can be processed either by frontend or by server depending on location. Now imagine coupling this table with this table...

just bite the bullet, go with pcre. do your best regarding migration/backward compatibility, but if there are things you cannot make work, document them extensively in the upgrade notes.
do respect the community, ask for feedback on a detailed spec to iron out the upgrade process and make it less painful.

On the other hand, since PHP provides no support for clear POSIX ERE, there is not much we can do. So we could just go and blame PHP in the docs.

How easy is it to identify/validate if provided pattern (in Frontend) uses PCRE features? I couldn't find anything useful out there.

man grep tells about POSIX ERE patterns, man pcrepattern tells about PCRE patterns. I think that no one faces the problem like ours. We have a chance to be the first to make automatic regular expression translation.

Or, at least, detection.

This issue is causing much pain. It would be nice if since there isn't going to be any movement in the PCRE direction. That there would be some extensive documentation around best practices to mitigate the lack of functionality that not having PCRE compatibility imposes on your user base.

joshuamcdo, supposedly support for pcre was finished yesterday. how exactly - we'll see when users start upgrading

I cannot say too much here , but I'm sure if you will take a look to a dev branch in the SVN, you should see that we can expect PCRE availability soon.

Example how to compile libpcre on AIX 5.2:

$ ./configure --prefix=`pwd`  --disable-cpp  --disable-shared --enable-utf8 --enable-unicode-properties
....
pcre-8.39 configuration summary:

    Install prefix .................. : /home/zabbix/andris/pcre-8.39
    C preprocessor .................. : gcc -E
    C compiler ...................... : gcc
    C++ preprocessor ................ : 
    C++ compiler .................... : 
    Linker .......................... : /usr/bin/ld
    C preprocessor flags ............ : 
    C compiler flags ................ : -g -O2 
    C++ compiler flags .............. :  
    Linker flags .................... : 
    Extra libraries ................. : 

    Build 8 bit pcre library ........ : yes
    Build 16 bit pcre library ....... : no
    Build 32 bit pcre library ....... : no
    Build C++ library ............... : no
    Enable JIT compiling support .... : no
    Enable UTF-8/16/32 support ...... : yes
    Unicode properties .............. : yes
    Newline char/sequence ........... : lf
    \R matches only ANYCRLF ......... : no
    EBCDIC coding ................... : no
    EBCDIC code for NL .............. : n/a
    Rebuild char tables ............. : no
    Use stack recursion ............. : yes
    POSIX mem threshold ............. : 10
    Internal link size .............. : 2
    Nested parentheses limit ........ : 250
    Match limit ..................... : 10000000
    Match limit recursion ........... : MATCH_LIMIT
    Build shared libs ............... : no
    Build static libs ............... : yes
    Use JIT in pcregrep ............. : no
    Buffer size for pcregrep ........ : 20480
    Link pcregrep with libz ......... : no
    Link pcregrep with libbz2 ....... : no
    Link pcretest with libedit ...... : no
    Link pcretest with libreadline .. : no
    Valgrind support ................ : no
    Code coverage ................... : no

$ make
$ make test
$ make install

$ ls -l include
total 73
-rw-r--r--   1 zabbix   zabbix        31706 May  3 19:08 pcre.h
-rw-r--r--   1 zabbix   zabbix         5452 May  3 19:08 pcreposix.h

$ ls -l lib
total 2637
-rw-r--r--   1 zabbix   zabbix      1297129 May  3 19:08 libpcre.a
-rwxr-xr-x   1 zabbix   zabbix          883 May  3 19:08 libpcre.la
-rw-r--r--   1 zabbix   zabbix        48806 May  3 19:08 libpcreposix.a
-rwxr-xr-x   1 zabbix   zabbix          943 May  3 19:08 libpcreposix.la
drwxr-xr-x   2 zabbix   zabbix          512 May  3 19:08 pkgconfig

$ ls -l bin
total 2829
-rwxr-xr-x   1 zabbix   zabbix         2406 May  3 19:08 pcre-config
-rwxr-xr-x   1 zabbix   zabbix       618363 May  3 19:08 pcregrep
-rwxr-xr-x   1 zabbix   zabbix       823913 May  3 19:08 pcretest

Example how to compile agent with libpcre on AIX 5.2:

Unpack Zabbix source code.
Compile the agent:

$ ./configure --enable-agent --prefix=`pwd` --with-libpcre=/home/zabbix/andris/pcre-8.39 2>&1 | tee my_configure.out
....
Configuration:

  Detected OS:           aix5.2.0.0
  Install path:          /home/zabbix/andris/zabbix-3.4.0alpha1
  Compilation arch:      aix

  Compiler:              gcc
  Compiler flags:         -g -O2 -I/home/zabbix/andris/pcre-8.39/include

  Library-specific flags:

  Enable server:         no

  Enable proxy:          no

  Enable agent:          yes
  Agent details:
    TLS:                   no
    Linker flags:               -L/home/zabbix/andris/pcre-8.39/lib 
    Libraries:                 -lperfstat   -lpcreposix -lpcre -liconv

  Enable Java gateway:   no

  LDAP support:          no
  IPv6 support:          no
....
$ make install 2>&1 | tee my_make_install.out

$ sbin/zabbix_agentd --version
zabbix_agentd (daemon) (Zabbix) 3.4.0alpha1
Revision 67815 13 September 2016, compilation time: May  3 2017 23:42:56

Copyright (C) 2017 Zabbix SIA
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it according to
the license. There is NO WARRANTY, to the extent permitted by law.

Supported technology levels: 5200

Example how to compile libpcre and Zabbix agent in Microsoft Windows 10 with Visual Studio 2017 RC and Cmake 3.8.0:

1. Unpack libpcre source code in a folder, for example D:\pcre\pcre-8.39 .
2. Make a build folder, e.g. D:\pcre\pcre-8.39\build and installation folder, e.g. D:/pcre/pcre-8.39_install .
3. Open commandline window "x64 Native Tools Command Prompt for VS 2017 RC" .
Go into D:\pcre\pcre-8.39 .
4. Start 'cmake-gui' command in the window.
Set "Where is the source code:" D:/pcre/pcre-8.39
Set "Where to build the binaries: D:/pcre/pcre-8.39/build
Press "Configure" button.
Set "Specify the generator for the project": NMake Makefiles
Use default native compilers: O
Initial default configuration is generated.
Change settings:

CMAKE_BUILD_TYPE: Release
...
CMAKE_INSTALL_PREFIX: D:/pcre/pcre-8.39_install
...
PCRE_BUILD_PCRECPP: Off
PCRE_SUPPORT_UNICODE_PROPERTIES: On
PCRE_SUPPORT_UTF: On

Press "Configure", press Generate", exit from 'cmake-gui'.
5. Compile libpcre with

cd build
nmake install

6. Before compiling on Windows, if you have checked out source code from SVN, prepare the 'dist' file on GNU/Linux:

$ ./bootstrap.sh
$ ./configure --enable-server --enable-proxy --enable-agent --enable-ipv6 --with-net-snmp  --with-libxml2 --with-libcurl --with-ldap --with-postgresql --prefix=`pwd` 2>&1 | tee my_configure.out
$ make dbschema
$ make install 2>&1 | tee my_make_install.out
$ make dist

7. Transfer the 'dist' file (e.g. zabbix-3.4.0alpha1.tar.gz) to MS Windows and unpack it in a folder, for example D:\zabbix-3.4.0alpha1
8. Open commandline window "x64 Native Tools Command Prompt for VS 2017 RC" .
Go into D:\zabbix-3.4.0alpha1 .
9. Compile agent with commands

cd build\win32\project
set PCRELIBDIR=D:\pcre\pcre-8.39_install\lib
set PCREINCDIR=D:\pcre\pcre-8.39_install\include

nmake /K -f Makefile_get
nmake /K -f Makefile_sender
nmake /K -f Makefile_agent
nmake /k -f Makefile_sender_dll

New compiled files are under D:\zabbix-3.4.0alpha1\bin\win64.

Successfully tested.

Fixed in:

• pre-3.4.0 r67925

(7) Updated general documentation:

• What's new
• Upgrade notes
• Requirements (listing 'libpcre3')
• Regular expressions ('POSIX extended' replaced by 'PCRE')
• Trigger functions, Low-level discovery ('POSIX extended' replaced by 'PCRE')

vso I think it would be better to say something like this:

Regular expression support in Zabbix has been switched from POSIX extended regular expressions to Perl Compatible Regular Expressions (PCRE) for enhanced regular expressions and consistency with frontend. While PCRE is mostly compatible with POSIX, still there are some differences such as the POSIX functions find the longest of the leftmost match, but PCRE stops on the first valid match, POSIX equivalence classes and collating elements are not supported. Those cases shall be handled by manually converting to PCRE compatible regular expressions equivalents.

glebs.ivanovskis "If regular expression is both POSIX and PCRE compatible then no action is required" - this is not exactly true, e.g. "\d" is both POSIX ERE and PCRE, but has different meaning. Quick demo:

$ echo 5 | grep -E '\d'
$ echo '\d' | grep -E '\d'
\d
$ echo 5 | grep -P '\d'
5
$ echo '\d' | grep -P '\d'

In any case it would make sense to check used regular expressions for special PCRE sequences that may have undesired effects.

andris Updated Requirements mentions 'libpcre3'. Apparently not all GNU/Linux distributions call it 'libpcre3'. CentOS 6 uses pcre-7.8-7.el6.

vso yes glebs.ivanovskis I removed this message, since it is at least redundant.

martins-v Thanks everyone for the discussion and input, I've rewritten the What's new / Upgrade notes entry. Also added a note to Requirements, mentioning that libpcre naming may differ depending on the distribution. RESOLVED

vso CLOSED

(11) How about adding to Upgrade notes:

Warning 2:
If you upgrade only server and proxies but some hosts will continue to use older Zabbix agents (before v3.4), those old agents still "understand" only POSIX regular expressions. Regular expressions used in their log[], logrt[] etc. items should not be modified to PCRE syntax until the agents are upgraded.

Hint 1:
GNU grep utility supports both POSIX extended regular expressions (with '-E' switch) and PCRE regular expressions (with '-P' switch). You can run it first with -E', then with '-P' switch with the regular expression and analyze a test file. If both outputs are not identical to expected one, the regular expression should be modified to work correctly after upgrade.

glebs.ivanovskis Note 1 on Hint 1: Seems that grep has it's own implementation of PCRE not based on libpcre, from man grep:

-P, --perl-regexp
Interpret the pattern as a Perl-compatible regular expression
(PCRE). This is highly experimental and grep -P may warn of
unimplemented features.

So 100% consistency between Zabbix and grep -P in not guaranteed... Maybe we can provide our own small command line utility for such testing.

Warning 2 (as I read it) basically says "nothing changes if everything stays the same". Too babysitting IMHO.

andris grep (GNU grep) 2.27 on Debian GNU/Linux 9 uses 'libpcre':
$ ldd /bin/grep | grep pcre
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f53cfff8000)

martins-v I've added the hint for now. What is suggested as Warning 2, I think is not worthy of a high-level warning, therefore I've added it as regular text. We already have one red box, which should alert users enough to pay attention to all that's written on the subject. RESOLVED

vso CLOSED

Maybe we can provide our own small command line utility for such testing.

Something in the web frontend would be superb for this. Especially if it permitted testing a regex against another item's history.

palivoda Does ZBXNEXT-3262 cover your request? If yes - more votes, please!

vso we already have test section in frontend, though it only says SUCCEED or FAIL to match.

ZBXNEXT-3262 would help some, and I've voted for it. What would be more useful would be something in the web frontend that would return what the match is for a given input. I use regex101.com for this, personally, but you probably don't want to punt Zabbix's entire user base at a third-party provider.

vso Please be so kind and create a separate feature request, you can mention it here if you would like.

Current workaround is:

GNU grep utility supports both POSIX extended regular expressions (with '-E' switch) and PCRE regular expressions (with '-P' switch). You can run it first with an '-E', then with a '-P' switch with the regular expression and analyze the test file. If both outputs are not identical to the expected, the regular expression should be modified to work correctly after upgrade.

Fixed in:

• pre-3.4.0 r68728

Add Feature requests for this:
ZBXNEXT-4041 - Zabbix log message for PCRE

Looks like there is a performance regression, reported in ZBX-15428.