BreakPoint
Regular Expressions Board
@Ray.R wrote:
From Philip Brooks:
Taking one step further, you could turn the first and third submatches into a non-capturing group to make the function more performant, and "conceptually more representative" of tossing the unwanted portion of the string:
(?:.*\^FD)(.*?)(?:\^FS$)
By doing this, you would also change the 'replace with' input from $2 to $1, since now only one backreference is created.
@JackDunaway wrote:
(?:.*\^FD)(.*?)(?:\^FS$)
By doing this, you would also change the 'replace with' input from $2 to $1, since now only one backreference is created.
Cool! Now I understand the non-capturing group better.
My example was given in respons to this forum post ...
My Regex-fu is weak... 
I've just realised that I needed to add some more requirements to the Regex expression that jack answered back here: http://forums.ni.com/t5/BreakPoint/Regular-Expressions-Board/td-p/1187799/page/8
And after hours of trying I've given up, but I know there must be an answer, because you can pretty much do anything with Regex.
Basically I need to make sure that the Version number
a) Matches one or two digits (first must be non-zero).
b) Optionally have a decimal point.
c) Optionally have one or two digits after the decimal point if it is present.
eg. 1, 11, 1.0, 1.00 are all valid version numbers
My Regex expression below works for most situations, but fails on two of them:
a) If I have GN0_v7._xxxx.mtt the version number will pass as "7." which I don't want, it should fail.
b) It will also accept GN0_v123_ or GN0_v1234 etc. which I can see why in my expression, but goodness knows how to fix it.
@ChrisReed wrote:
I've just realised that I needed to add some more requirements to the Regex expression that jack answered back here: http://forums.ni.com/t5/BreakPoint/Regular-Expressions-Board/td-p/1187799/page/8
And after hours of trying I've given up...
A quick go at it, try this: _[vV]([1-9][0-9]?(?:\.[0-9]{1,2})?)_
The key is the Non-Capturing Group, and also pulling the decimal literal out of the Character Set.
It appears to pass the test cases from your example:
PS -- In the future, copy your current Regex and Test Cases into the browser, rather than a screenshot or even a VI Snippet -- this is the easiest way to get support for Regexes 🙂
Thanks Jack, works great - now I know how to use Non-Capturing Groups ie. ?:
Will remember to use Snippets next time or attach the VI 
Chris
Oftentimes, when performing a Regex match using the Match Regular Expression node, a somewhat-confusing Lookaround can be replaced by Non-Capturing Groups and Submatches. Since the 'Whole Match' output is unused in favor of a 'submatch' output, it's not too big a deal that the Non-Capturing Group is a non-zero width assertion.
But today I ran across a use where zero-width assertions necessitate Lookarounds: while using the Search and Replace String node configured to match Regular Expressions.
This string replacement operation always replaces the full match; yet we want some input characters to constrain the match, while remaining un-replaced -- that sounds like a zero-width assertion!
The regular expression (?<=\[)foo(?=\]) matches the literal foo but only when it's surrounded by square brackets, without including the brackets as part of the match. How cool is that?!
Read more here about Positive Lookaheads and Positive Lookbehinds (generally, Lookarounds) and remember how these zero-width assertions might come in handy whilst using Search and Replace String.
Just stumbled upon a sweet application for visualizing regular expressions, not unlike a LabVIEW block diagrams: it's called Debuggex.
Taking an example from above, Debuggex will produce the following output:
Try this example yourself -- note that you can single-step through the regex using the slider:
The Match Regular Expression function has two optional inputs, multiline? and ignore case?
Both of these flags can be specified within the regular expression itself using Matching Mode directives.
The snippet below illustrates the syntax of prepending your Regular Expression with Matching Mode directives.
What's the benefit? Now your matching behavior is fully expressed as one atomic expression, rather than an expression and Boolean inputs; additionally, you have access to the useful Single-Line Mode, not available as a node input:
Note that all four Regular Expressions above are identical, except for the Matching Mode directives. The final expression matches the input, since it's configured to both Ignore Case and also Match Newlines with Dot.
(Note: this is one of the few that you can't test with RegexPal, since the Javascript Regex syntax differs from PCRE syntax)
Input Text:
Outside a dog, a
Regex is a man's best friend. Inside
a dog, it's too dark to match.
Regular Expressions, where only the last one matches:
A.REGEX.IS.A.MAN'S.BEST.FRIEND
(?i)A.REGEX.IS.A.MAN'S.BEST.FRIEND
(?s)A.REGEX.IS.A.MAN'S.BEST.FRIEND
(?is)A.REGEX.IS.A.MAN'S.BEST.FRIEND
@altenbach wrote:
Cool!
(Shouldn't the last line in the diagram comment be (?x)?)
Indeed; good catch; additionally, I scrimped a couple "L"s while spelling "available" in that comment 😉
And to continue this topic -- you can toggle Matching Mode directives at any point in the regex. To "turn off" a matching mode directive, use a minus sign (hyphen) before the mode identifier.
Multiple modes may be toggled in one directive group, as illustrated below with some nonsensical regular expressions:
(?is)first(?-i)second
(?ism)first(?x-is) s e c o n d
Typically, these directives are placed at the very beginning in order to apply to the entire regex, but it's sometimes desirable to toggle matching modes at arbitrary locations withing a given regex:
Input:
Once upon a midnight dreary, while I pondered, weak and weary,
Over many a quaint and curious volume of forgotten lore
Regular Expressions to test:
midnight dreary
MIDNIGHT DREARY
(?i)MIDNIGHT DREARY
(?i)MIDNIGHT(?-i) DREARY
(?i)MIDNIGHT(?-i) dreary
MIDNIGHT(?i) DREARY
midnight dr(?i)EARY
