Regex engines come in various flavours:
✽ .NET flavor, when programming in C#.
✽ PCRE flavor, when programming in PHP and for Apache.
✽ Matthew Barnett’s regex module for Python.
✽ POSIX Extended Regular Expression flavor (ERE) in mySQL.
✽ JGSoft flavor, for search and replace in EditPad Pro.
✽ TR1 flavor, to rename files in Directory Opus.
✽ ABA flavor (loosely based on Henry Spencer’s library) in ABA Search Replace.
What Regex engine is installed in Make’s Text Parser and
Text Parser - Match Pattern (make.com)
It is also implied that replace() is using a subset of the same flavor.
String functions - replace (make.com)
"See Text parser's documentation for further information on regular expressions."
Additional note: Although the replace documentation reads that “Regular expressions (enclosed in ‘/…/’ ) can be used as search string with a combination of flags (like ‘g’ , ‘i’ , ‘m’ ) appended:”, my testing showed that ‘g’ (global) and ‘i’ (case insensitive) work, ‘m’ (multiline) and ‘s’ (single line) do not.
Make (and more specifically IML functions) are built on top of JS, so Jim’s answer is accurate here. This is also relevant when dealing with problems related to numerical representation. For instance: you can see rounding errors when representing long numerical strings within functions.
The replace() function is indeed more limited in its comprehension of RegEx flags than the RegEx Parser module at the moment.
I want to outline that @alex.newpath is not an isolated case, I also faced the same confusion a while ago and it also made me lose time and energy.
You always want to know which flavor to use as they are all so different, and I concur that it is not even documented besides the vague hint that @JimTheMondayMan mentioned. Now that I remembered that is also what allowed me to guess the flavor back then.
A super easy one-point-in-a-sprint fix would be to add the flavor to the hint, directly in the regex parser module.
Again, this makes you lose time and energy and you should never have to guess such an important information.
Regular expressions aren’t so regular after all, huh?
Providing a flavour of regular expression I’m afraid won’t help too many people because it won’t really specify what’s allowed and what’s not allowed. A UI hint here may only serve to confuse, as this sort of nuance is reserved for advanced makers.
I think this clarification is something that would work well in the help docs for the text parser.
To help Makers new to using regular expressions in Make, validation of the expression similar to how regex101.com does it, would be better. The Make UI should confirm whether your regular expression pattern is:
- valid and
- supported in the Make regex engine
- that using a regular expression is supported in a particular IML function or text box in the Make UI
But alas, then it’s not a 1 point fix being scoped like that.
I think the
split() function also uses regular expressions when defining the second argument for the delimiter.