Several implementations of regular expressions differ from each other in subtle ways which is

Question

0

Asked: May 25, 20262026-05-25T13:39:19+00:00 2026-05-25T13:39:19+00:00

Several implementations of regular expressions differ from each other in subtle ways which is

0

Several implementations of regular expressions differ from each other in subtle ways which is the source of much confusion when I try to use them.

Most of these differences include the semantics related to whether a character is escaped or not. This is most often an issue with parentheses, but can apply to curly brackets and others. This is probably a consequence of the syntax of the language or environment in which the implementation is found. For instance, if the $ symbol indicates a variable name in some language, one can expect regular expressions represented in that language would require escaping the “end of line” anchor to \$ or some such. But what gets confusing at this point is how you would represent an actual dollar sign. I believe Perl gets around this by wrapping a regex inside forward slashes /.

Similarly there are escapes for specific characters themselves, for instance non printing characters such as \n and \t. Then there are the similar looking generic character groups such as \d for digits, \s for whitespace, and \w which I just learned covers underscores as well as digits. I found myself on several occasions trying to use \a for a “alphabetical” group but this only ended up matching the bell character 0x07.

It’s pretty clear that there is no simple and one-shot solution to knowing all of the differences in features and syntax offered by the myriad of implementations of regular expressions out there, short of somebody doing all the hard work and putting results in a well organized table. Here is one example of exactly this, but of course it doesn’t cover several of the programs that I use extensively myself, which include vim, sed, Notepad++, Eclipse, and believe it or not MS Word (at least version 2010, I suspect 2007 also has this, they call it “wildcards”) has a simple regex implementation too.

I guess what I want is to be as lazy as possible (in a certain sense) by trying to come up with a way to determine for any given regex implementation what its “escape settings” are beyond any doubt by applying one (or a few) queries.

I’m thinking I can make a file which contains test cases, along with a huge regex query, and somehow engineer it so that running it once will show me exactly what syntax I need to use subsequently without doubting myself any further. (as opposed to having to edit files and use multiple queries to figure out the same thing which gets terribly old after a while).

If nobody else has attempted to construct such a monstrosity, I may undertake this task myself. If it’s even possible. Is this possible?

I tried to come up with an example (it was just to figure out if EOL anchor is $ or \$) but in every case I had to use a multitude of different search/replace queries in order to determine how the program will respond to the input.

Edit: I came up with something using capturing and backtracking. I gotta work on it a little more.

Update: Well, Notepad++ does not implement the OR operator commonly denoted by the pipe |. Word’s “wildcards” is a poor substitute also, it doesn’t have | or *. I’m fairly certain that missing any of the regular expression operators (union, concat, star) means it cannot generate a regular grammar, so those two are ruled out.

I can create an input file like this:

$
*
]
EOL

and query

(\$)|(\*)|(\[)|($)

replacing with

escDollar:\1:escStar:\2:escSQBrL:\3:Dollar:\4:

yields a result of (assuming unescaped parens is group and unescaped pipe is or)

escDollar:$:escStar::escSQBrL::Dollar::
escDollar::escStar:*:escSQBrL::Dollar::
]escDollar::escStar::escSQBrL::Dollar::
EOLescDollar::escStar::escSQBrL::Dollar::

I ran this in vim. This output would demonstrate the single characters that are matched by each item specified next to it, i.e. the escaped dollar sign item is seen to match the actual dollar sign character rather than the non escaped dollar sign item at the end.

It’s difficult to see what’s going on with the $ anchor since it matches zero characters, but it shouldn’t be hard to find a solution for it. Besides it’s not a commonly mistaken one. The ones I’m particularly worried about are pipe and parens and the different brackets. When you’ve got 4 different types in there there are 2^4 combinations of escaped and non-escaped versions of them you can use. Trial-and-error with that is horrific.

This output isn’t too hard to parse at a glance, and is also seriously easy to process as part of a script. The one glaring problem that remains is figuring out whether parens and pipe need to be escaped. Because the functionality of the whole thing depends on them.

It would seem like that will require multiple queries. It may be possible with a cleverly engineered jumble of backslashes, parens, and pipes to figure out the combination (only 4 possibilities after all) with an initial query, then choose the subsequent matrix generator query based on it.

Something like this shows it can work:

(e)
(f)

querying

\((f\))|\|\((e\))

replace with

\1:\2

would produce:

:(e if escaped parens is group and escaped pipe is or
:e) if parens is group and escaped pipe is or
(f: if escaped parens is group and pipe is or
f): if parens is group and pipe is or

I still don’t really like this though because it requires a second query on a second set of input. Too much setting up. I may just make 4 copies of the “matrix” thing.