Search and Replace vs Match Pattern

[Bob_Schor]

I wanted to write a VI that would take an array of strings, a Search Pattern that adheres to the "simple Regular Expression" rules used by the Match Pattern function and the Search and Replace (with Regular Expression enabled), and return the sub-array matching the pattern.

I started with Search and Replace, with Regular Expressions turned on.  I set "Ignore Case" to True, and didn't wire the Replace String.  I used as a "Match occurred" the expression "Number of Replacements > 0" (I get the same result if I use "Offset past Replacement < 0").  When my Search String is an empty string, it returns 0 replacements, and Offset past Replacement of -1, though the Detailed Help says "If search string is an empty string and replace all? is FALSE, the function inserts replace string  at the beginning of input string."  I (naively?) interpret this as "If the search string is an empty string and replace all? is False, there will be one replacement made at the beginning of the input string".  I also assume (but this could also be wrong!) that replacing something with an empty string is still a replacement.

I tried doing the same thing with the Match Pattern function, which does not have a "Replace all?" option and does not return the Number of Replacements.  It (correctly, in my opinion) tells me when my Search string is an empty string, it inserted the (empty) Replacement string at Position 0 of my Input string, i.e. it behaves the way the Help description suggests that it should (and has the functionality I need).

Two questions.  First, is this a "Bug" or a "Feature" of Search and Replace (with Regular Expressions)?  It certainly seems like a "Bug" in not adhering to the Help Documentation, but it has probably been working this way as a Feature for too long to risk "fixing" and breaking who-knows-how-many existing VIs.  An alternative to Fixing the Bug is to Fix the Documentation to clarify this behavior.

Second question is what is the rationale for having slightly different behaviors for these two functions?  True, they are slightly different (Match Pattern has fewer options and no Error Lines), but it's not really clear (other than Legacy Support) why both are needed.  It is even less clear why they have different behaviors when the Search string is an empty string (certainly wasn't clear to me from the documentation).

Bob (Trouble-Maker) Schor

[camerond]

Bob, I'm not really sure what you're saying, I get what I interpret as the documented behavior in both cases. Here's how I see it:

First, in the "Search and Replace" function, the help doc says that if the search string is empty, the replace string is inserted. I figure that doesn't mean replace, but just stuck in. That would be consistent with the "Number of Replacements" answer.

Second, the "Match Pattern" function doesn't replace anything, it just parses the original string into before, at, and after segments. Since an empty string is instantly matchable, the zeroth (not computer-counting zero, but real counting zero) character is "matched" and everything in the string is after it. The function only does this once, so there is no opportunity for finding a second "empty string." If you wire the "after match" output of this function to the input string of another Match Pattern, you get the same result, sonce you are starting over with the same string as input.

But I really don't see why the Help docs say these two functions are similar, to me they are completely different. I can only guess that they mean they are both searching-type functions with similar criteria for finding a match. That, IMHO, needs to be deleted from the docs to prevent confusion and I would call this situation, if anything, a bug.

(Unsolicited opinion) I also would really like LV to use PCRE regular expressions without the extra caveats that LV imposes, i.e., in Match Pattern, you cannot use (, ), or | as metacharacters, and in Match Regular Expression, you cannot have null characters in strings. Having both of these restrictions makes it really awkward to use regexes on binary string data. (\Unsolicited opinion)

Cameron