bob wrote:If they want to use oddball definitions of regular expressions, I don't care. I was simply pointing out a potential problem if it interpreted regular expressions in a standard way.
That you haven't heard of something doesn't make it oddball. It just shows your own susceptibility to limitation. There is not only one standard for regular expression no matter how hard is for you to see that. Beside POSIX there is also PCRE standard which is much more powerful than 20+ years old POSIX and many modern languages such as Java, JavaScript, Python, Ruby, Microsoft's .NET Framework, and XML Schema use its flavour.
Regular expression syntax has been defined since the 50's (look up Stephen Kleen), sorry. They have been taught in compiler and theory courses for that same period of time.
"perl-compatible-regular-expressions" does NOT a standard make. Just shows how they were implemented in Perl, nothing more, nothing less. Pick up any good computer science theory text, then report back after you have educated yourself a bit rather than just trying to argue / insult, which is typical. And for the record, there are a bunch of significant differences between PCRE and perl regular expressions.
bob wrote:If they want to use oddball definitions of regular expressions, I don't care. I was simply pointing out a potential problem if it interpreted regular expressions in a standard way.
That you haven't heard of something doesn't make it oddball. It just shows your own susceptibility to limitation. There is not only one standard for regular expression no matter how hard is for you to see that. Beside POSIX there is also PCRE standard which is much more powerful than 20+ years old POSIX and many modern languages such as Java, JavaScript, Python, Ruby, Microsoft's .NET Framework, and XML Schema use its flavour.
Regular expression syntax has been defined since the 50's (look up Stephen Kleen), sorry. They have been taught in compiler and theory courses for that same period of time.
"perl-compatible-regular-expressions" does NOT a standard make. Just shows how they were implemented in Perl, nothing more, nothing less. Pick up any good computer science theory text, then report back after you have educated yourself a bit rather than just trying to argue / insult, which is typical. And for the record, there are a bunch of significant differences between PCRE and perl regular expressions.
Today PCRE is in fact more common than any of the (many) different RE implementations that you find in UNIX tools. sed, grep, egrep, vi, and sh/bash/csh/ksh all have their own RE (and certainly I forgot some others). So the POSIX RE "standard" does in fact exist mostly in theory since the biggest part of the UNIX tools listed above were already there when POSIX came up, and AFAIK they were not changed substantially regarding RE afterwards. That current Perl RE has differences to PCRE is correct since Perl and PCRE are developed independently. PCRE is similar to RE of Perl 5. Call it a standard or not, at least it can be seen as a "de facto standard" in parts of our IT world ...
Whether PCRE is more "powerful" than POSIX RE, or than the RE actually used in the most important UNIX tools, is something I don't want to judge. I have never missed anything important when using any of the UNIX tools above, I can do everything I want with each of them.
Most of these different RE implementations, including PCRE, still have a lot in common, though, so that this discussion may be kind of "academic"
Adam Hair wrote:I understand. The answer I gave Frank takes advantage of the format of his text file and it is not a general solution.
Your answer is perfectly correct and is general solution for Frank's problem for PCRE based regular expression matching. That Bob didn't hear about it is his fault.
Given the expression (9.*)d and the following string:
9 abcd 10 abcd
Will PCRE based regex match the first or second d? I don't have a computer available and I am not adept with regex. I simply have learned enough to do what I have needed to do.
Adam Hair wrote:I understand. The answer I gave Frank takes advantage of the format of his text file and it is not a general solution.
Your answer is perfectly correct and is general solution for Frank's problem for PCRE based regular expression matching. That Bob didn't hear about it is his fault.
Given the expression (9.*)d and the following string:
9 abcd 10 abcd
Will PCRE based regex match the first or second d? I don't have a computer available and I am not adept with regex. I simply have learned enough to do what I have needed to do.
The second d (more precisely: the last one, as .* matches "as much as possible"), same as with the UNIX tool "sed". To match the first d would require the non-greedy variant:
(9.*?)d
That means, Frank might better try (9.*?)d instead of (9.*)d , despite the claim of Milos ...
EDIT: Even better (since the "9" must be found at the beginning of a line if I understood correctly):
Adam Hair wrote:I understand. The answer I gave Frank takes advantage of the format of his text file and it is not a general solution.
Your answer is perfectly correct and is general solution for Frank's problem for PCRE based regular expression matching. That Bob didn't hear about it is his fault.
Given the expression (9.*)d and the following string:
9 abcd 10 abcd
Will PCRE based regex match the first or second d? I don't have a computer available and I am not adept with regex. I simply have learned enough to do what I have needed to do.
The second d (more precisely: the last one, as .* matches "as much as possible"), same as with the UNIX tool "sed". To match the first d would require the non-greedy variant:
(9.*?)d
That means, Frank might better try (9.*?)d instead of (9.*)d , despite the claim of Milos ...
EDIT: Even better (since the "9" must be found at the beginning of a line if I understood correctly):
Find: ^(9.*?)d
Replace with: $1a
Tested with Notepad++
That was my original concern, as mentioned. Milos strikes again.
