The macOS regex library rejects a regex like "SHM_[A-Z]+[[:space:]]+[0-9]{6}+" since there is an additional + character after the {N} group. I believe this should not be accepted since there is already a quantifer after the [0-9]. See also https://svnweb.freebsd.org/changeset/base/339635
Tagging this for PRs that I'll close once bsdgrep becomes the default -- regex(3) actually does reject this, as exemplified by: $ echo "SHM_FOOO 000000" | bsdgrep -Ee 'SHM_[A-Z]+[[:space:]]+[0-9]{6}+' grep: repetition-operator operand invalid
A commit references this bug: Author: kevans Date: Tue Dec 8 14:05:27 UTC 2020 New revision: 368439 URL: https://svnweb.freebsd.org/changeset/base/368439 Log: src.opts.mk: switch to bsdgrep as /usr/bin/grep This has been years in the making, and we all knew it was bound to happen some day. Switch to the BSDL grep implementation now that it's been a little more thoroughly tested and theoretically supports all of the extensions that gnugrep in base had with our libregex(3). Folks shouldn't really notice much from this update; bsdgrep is slower than gnugrep, but this is currently the price to pay for fewer bugs. Those dissatisfied with the speed of grep and in need of a faster implementation should check out what textproc/ripgrep and textproc/the_silver_searcher can do for them. I have some WIP to make bsdgrep faster, but do not consider it a blocker when compared to the pros of switching now (aforementioned bugs, licensing). PR: 228798 (exp-run) PR: 128645, 156704, 166842, 166862, 180937, 193835, 201650 PR: 232565, 242308, 246000, 251081, 191086, 194397 Relnotes: yes, please Changes: head/share/mk/src.opts.mk
Missed this one; not an issue since the replacement of grep.