I cannot vouch for the OpenBSD people, but a reason why bounds / interval expressions are not supported in OpenBSD's and most other awk implementations may be because they're a horrible botch, implementation-wise.
I'll start with a testcase, using GNU awk (gawk
), which supports them:
time echo | gawk '/a{1,30000}/'
# still going strong, after 5 minutes with the CPU at 100%
# and eating up > 4G of memory
Because awk is using real regular expressions (the state-machine / finite automaton kind, NOT the recursive / backtracking space & time unbounded kind from perl), counted repetitions could only be implemented by statically repeating the regex subexpression in code, as many times as necessary.
A regex like a{1,4}
is actually turned into something like a(a(aa?)?)?
at compile time. You can easily see how nasty this is with anything but very small repetition counts: even a puny /a{1,500}/
will take half a second and many MBs of memory.
Despite being mandated by POSIX, as of April 2020, interval expressions are NOT supported in the default awk from Debian 10 (Buster), OpenBSD 6.6 and FreeBSD 12.1, and the /usr/bin/nawk
from Solaris 11. Except for Debian (which is using mawk
) all the other are based on the traditional nawk ("new awk").
Besides GNU awk, awk implementation which do support interval expresssions are the busybox awk, and the default awk from NetBSD and MacOS.
The purported descendant of nawk (bwk, "one true awk") has also recently included support for interval expressions, a move which was IMHO absolutely NOT well though-out.
POSIX has a history of mandating broken requirements for awk, that then have to be retired; an example of this is the requirement that 0=="000"
should evaluate to 1 (true), which was dropped in the current version of the standard, but which unfortunately has made its way into the /usr/xpg4/bin/awk
from Solaris, making it unusable.
[0-9]?[0-9]?[0-9]?
. Actually I settled on the more correct expression[1-9][0-9]?[0-9]?
. That does not answer however why OpenBSD awk does not work as documented.