These already do not work in many tools which require those special characters to be escaped to have any meaning. An easy example is GNU grep, sed, etc. which use BRE ("Basic Regular Expressions") by default. The article mentions GNU coreutils but does not explain that `-E` is required to fix that behavior.
It does not support the + repetition operator.
https://json-schema.org/understanding-json-schema/reference/...
Here are some of the [more popular][1] ones, and then there are PCRE and Python.
It took me a while to learn that some of the older ones you see in e.g. grep are [specified by POSIX][2].
[1]: https://cppreference.com/cpp/regex#Regular_expression_gramma...
[2]: https://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd...
.
^, $
[…], [^…]
\*
\w, \W, \s, \S
\1 - \9 backreferences
\b \B
? +
| alternation
{n,m} for counting matches
(...) capturing
- \w, \W, \s, \S - need to use POSIX classes instead: [[:alnum:]], [^[:alnum:]], [[:space:]], [^[:space:]]
- \b - need to use use [[:<:]] (word start) and [[:>:]] (word end) instead
- \B - (not a word start/end) no alternatives
I find it a good reading.
https://en.wikipedia.org/wiki/SNOBOL
> In the 1980s and 1990s, its use faded as newer languages such as AWK and Perl made string manipulation by means of regular expressions fashionable. SNOBOL4 patterns include a way to express BNF grammars, which are equivalent to context-free grammars and more powerful than regular expressions. The "regular expressions" in current versions of AWK and Perl are in fact extensions of regular expressions in the traditional sense, but regular expressions, unlike SNOBOL4 patterns, are not recursive, which gives a distinct computational advantage to SNOBOL4 patterns.
1. You can not compose a bigger regexp out of smaller ones
2. A regexp can not "call" other regexps
Even beyond the regex syntax itself, you often also start running into encoding problems when trying to actually use them. Typing the regex in a shell? Make sure to esacpe stuff properly. Regex in Python? Make sure it's a raw string. Etc etc etc
It's a modern miracle we're at least within rhyming distance of how to write regexes in most tools.
[0]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx...
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
This para caught my eye;
A SNOBOL pattern can be very simple or extremely complex. A simple pattern is just a text string (e.g. "ABCD"), but a complex pattern may be a large structure describing, for example, the complete grammar of a computer language. It is possible to implement a language interpreter in SNOBOL almost directly from a Backus–Naur form expression of it, with few changes. Creating a macro assembler and an interpreter for a completely theoretical piece of hardware could take as little as a few hundred lines, with a new instruction being added with a single line.
Also this;
SNOBOL4 pattern-matching uses a backtracking algorithm similar to that used in the logic programming language Prolog, which provides pattern-like constructs via DCGs. This algorithm makes it easier to use SNOBOL as a logic programming language than is the case for most languages.
Seems like there are some hidden superpowers waiting to be unlocked ;-)
And I’d further bet that people who are casual about specifying that are relatively strongly correlated with people who are casual about santization, catastrophic backtracking, etc. (At least based on code I’ve seen over the decades.)
let s = "abc" + "def";
let regExp = /abc/ + /def/;
/abc/ + /def/
?
"my name is (.*?)$" => my name is k0in
Or values "last (.*?), was great" => last sunday, was great
> I don't know what language your program is even written in!
I legitimately don't understand how you're in this situation. If the documentation is telling you that something is a regex, and it's not a user-supplied regex, then that's something intended for fellow developers. If configuration expects a regex for some reason, that's a signal that you're expected to be a programmer to use the software; and you're presumably interested in it because you use the same language, or are at least familiar enough with the open source ecosystem to look these things up. If the software were meant to be used by people who can't do these things, it would be designed without those rough edges, but more importantly the documentation would be getting written by a non-developer.
1) What?
Only programmers are expected to use grep? What? That's absolute nonsense. Even programmers aren't programmers during every waking hour. My being a programmer in general doesn't make me a developer of your project, and I shouldn't have to become one by git cloning it to figure out how to write a config file.
Google Sheets and Excel have a REGEXMATCH. Do I have to be a programmer to use a spreadsheet? And even if so, do I need to guess the implementation language? No, because Google and Microsoft document their regular expression dialects (RE2 and PCRE, respectively), so you don't have to guess.
> If the software were meant to be used by people who can't [develop]...the documentation would be getting written by a non-developer
2) What?
No, that's also nonsense. Developers write programs for non-developers ALL THE TIME without some kind of technical writer intermediary. If the developer is any good, he'll realize that "regex" in documentation is ambiguous and write down the specific language he means.
The most frustrating aspect of regular expressions is that implementations vary. Features supported in one tool may not be supported at all in another tool, or they may be supported with slightly different syntax.
I learned regular expressions in the context Perl, a maximalist regex environment. This led to frustration when features I expect to work are missing [1]. One way around this is to use Perl analogs of other tools, but this is very non-standard. I want to be able to send colleagues and clients code that works out of the box.
As I mentioned in my post on computational survivalism, I occasionally need to work on computers that I cannot install software on. So a better approach is to identify a subset of regex features that work everywhere. The stricter your definition of “everywhere” the less this includes. The strictest subset would be
[…]. * ^ $A more relaxed definition of “everywhere” would be the tools you most care about. Currently the tools I most want to use with regular expressions are sed, awk, grep, and Emacs.
If you use the Gnu versions of sed, awk, and grep, and use the -E option with sed and grep, then the list of common features is bigger. The regular expression features of the three tools are similar, and awk’s features are supported in the other tools, with one exception: word boundaries in awk are \< and \> rather than \b and \B.
I wrote about Awk’s regex features here.
Emacs supports analogs of most of awk’s regex features. However, the characters
+ ? ( ) { } |
all require a backslash in front in order to act like the awk counterparts. Also, the analog of \s and \S in awk is \s- and \S- in Emacs.
Instead of meaning space or nonspace, \s and \S in Emacs begin a (negated) character class, and one of those classes is - for space. But there are many others. For example, \s. stands for a punctuation character and \S. stands for a non-punctuation character.
So for my definition of “everywhere,” with the caveats mentioned above, the following features work everywhere. YMMV.
.
^, $
\[…\], \[^…\]
\*
\\w, \\W, \\s, \\S
\\1 - \\9 backreferences
\\b \\B
? +
| alternation
{n,m} for counting matches
(...) capturing
One footnote is that gawk supports backreferences in replacement strings but not in regular expressions per se.
[1] To some extent, basic Perl features work elsewhere and advanced features do not, depending on your idea of what is basic or advanced. I think of look-around features as advanced, and that tracks. But I think of \d for digits as basic, but that’s not supported in many regex flavors.