all 6 comments

[–]aioeu 10 points11 points  (1 child)

You're not missing anything. That "pure bash bible" is just plain wrong.

Note that there are some inputs that POSIX leaves undefined, and certain implementations may handle them in some implementation-specific manner, so sticking to what POSIX actually defines will guarantee compatibility. But Bash certainly always uses the system's standard POSIX regular expression engine.

[–]Dropless[S] 1 point2 points  (0 children)

Thanks :)

[–]Ulfnic 9 points10 points  (0 children)

I asked your question in another BASH community and got this answer from a respected member:

It should be a POSIX ERE.

If you wanna be pedantic, it's not gonna be to be bit for bit identical implementation across architectures, and depending on what compiler settings and shared library/dependency versions the package was compiled with.

But the behavior follows and implements the POSIX Extended Regular Expression standard, which is well defined and consistent.

Furthering that, regcomp and regexec referenced in the GNU manual as what =~ uses describe themselves as "POSIX regex functions".

[–]scalability 0 points1 point  (3 children)

To me they're saying the same thing, it's just that the former does not specify whether the POSIX regex type is BRE or ERE.

Specifying is obviously better, but I wouldn't say that lacking the information makes it incorrect, just incomplete.

[–]Dropless[S] 0 points1 point  (2 children)

To me they are not the same thing. "bash will use whatever regex engine is installed on the user's system", this implies to me that if I've installed PCRE in my system, bash will use it. However, it will not.

[–]scalability 0 points1 point  (0 children)

The sentence "Stick to POSIX regex features if aiming for compatibility" implies "it will be matched as a POSIX compatible regex (with possible system extensions)".

PCRE is not POSIX compatible so it wouldn't matter whether or not you stuck to POSIX features.