Procmail fails to parse Regex with curly braces for counting occurences

[PoC-dev]

Tested with version 3.22-26 (Debian 11).

When using a recipe like the following:

LOGFILE=/home/myuser/.procmail-log
VERBOSE=yes

:0
* ^Subject: Numericvalue:[0-9]{5}$
|mail/Othermbox

mails successfully tested with egrep don't match in procmail. Single or double-escaping the curly braces also doesn't work.

procmail: No match on "^Subject: Numericvalue:[0-9]{5}$"

Poking in the dark: Could it be that the recognition of curly braces clashes with grouping of rules also using curly braces?

[tripleee]

Procmail's regex implementation never included this particular detail of egrep syntax (though you could argue that the documentation should not say it is egrep-compatible then).

[PoC-dev]

Thank you for clarifying. I wonder why procmail apparently doesn't use the system provided regex functions in libc? Probably because older and not all libc implementations have/had regex "built in"?

I think the least amount of work would be to just update the according documentation, list exceptions to the alleged ereg compatibility, and leave it be.

Furthermore, it could be beneficial to tweak procmail source and its build process to incorporate system provided regex library functions, if detected at build time. procmail -v should then output what kind of regex functions are compiled in (original procmail vs. system). I guess this would enable full ereg compatibility with the least amount of labour for the majority of users.

What do you think?

[tripleee]

I'm not srb, but I don't think he will be eager to take on an external dependency. There are some details in Procmail's regex implementation which are quite specific to Procmail.

Having said that, providing repetition support would not technically be very hard, but then that would break all legacy recipes which use literal curlies.

[PoC-dev]

I'm not srb, but I don't think he will be eager to take on an external dependency.

Therefore my suggestion to make it optional.

Having said that, providing repetition support would not technically be very hard, but then that would break all legacy recipes which use literal curlies.

Good point.

I repeat my other suggestion to update the documentation accordingly and leave it be.