Regex Search Repetition doesn't work?!
 

In the past I was using repetition searches like
quite often using Sigil running on a Windows 7 machine. Recently I changed to a Windows 10 machine and suddenly those searches don't work anymore? :(
I've tested with several patterns likeSo it behaves completely strange and only finds the number of characters before the Comma, but no range... :blink:

In the first step I suspected Sigil and installed the previous version 0.9.8 in parallel (yes, that works, even it requires some renaming of folders), but it showed exactly the same behavior.

As far as I've seen regex is handled by the PCRE engine, but that doesn't seem to be dependent from Java versions etc, right?
Any idea where to look at?

Thanks for any hint!

Perhaps some other app on Windows 10 has a different or broken pcre library someplace in your path?

With PCRE being statically built and linked into the Windows Sigil binary, is that even possible?

I'm assuming, of course that the OP is using the official released version of Sigil and hasn't custom compiled Sigil using system libraries.

I've just tested [a-zA-Z]* on my Windows and Linux machines and didn't get any matches either. However, [a-zA-Z]+ worked. Does [a-zA-Z]* work on your Mac?

[0-9]{1,} works on my Windows and Linux machines.

Edit: The regex works, but only if the cursor is positioned before a letter.

Indeed I got the official release 0.9.9, didn't even try to compile it myself (since years I'm just a stupid user of the extremely good Sigil).
I don't have anything using a PCRE lib in my path. Well, there is one other program, but after installing it hasn't even started yet.

But there seems to be another problem if Doitsu is having a similar issue, even it is just a subset of mine?

Tried the following on a Mac and it worked exactly as expected:

It first highlighted the "an: B" and then next highlighted the "an: " since we specified the * which allows 0 occurrences of the [a-zA-z] set.

So regular expressions seem to work just fine on a Mac.

Would someone with access to Windows please try this exact example and let me know if it works correctly or not.

Shouldn't be possible if statically linked.
But then I am out of ideas. A locale issue?

I'll do some testing when I get home.

I haven't looked at the config for the bundled PCRE in a long, long time, so I can't remember if there's differences in how it's configured on Mac vs Win/Lin. I do know that nothing has changed on the bundled PCRE front for a very long time, though.

EDIT: I guess I made a very minor change two years ago to clean up some Windows compiler warnings, but I really can't imagine that being the issue. I'll certainly check to make sure, though.

Tried the following on a Mac and it worked just fine (ie. it was greedy as expected)
It it properly found the 333 which is what I expected. So min and max match counts work properly on a Mac as well.

Would someone please try this on Windows and let me know if it works correctly or not.

Tried that search with your XML code (btw you missed the < in the beginning) under Windows and did the search again, of course enabled regex.
Result: found exactly the first "33" of the string "333". :chinscratch:

Looking forward to the results of DiapDealer. :o

* + and {min, max} repetition should all be greedy by default. Are certain you're adding or changing nothing in an attempt to affect the default greediness of Kevin's tests?

I wasn't able to reproduce Wasserpulle's result. On my Linux and Windows 10 machines 3{2,4} matched 333 not 33.

I get the same (and expected) results as KevinH and Doitsu on Windows 10.

@Wasserpulle: I'm guessing if Kevin's second test is only matching "33" for you, that you have the Minimal Match option checked. That overrides PCRE's default greediness behavior (including the greediness of repetition). If you uncheck it, you should get the same results as us.

That could also easily explain the results you describe in the very first post.

With the cursor in front of a string of alpha characters, [a-zA-Z]* isn't going to match anything when Minimum Match is checked. Because the minimum match of an expression that's allowed to return nothing will always be nothing.

{1,} should only match the first occurrence if Minimal Match is checked.

Same with {2,4}. With Minimal Match checked, it will never match anything other than the first two occurrences of the criteria.

3{2,4} with Minimum Match checked is essentially the same as searching for "33" -- which is why that's what it matches for you.

Yes, thanks. Copy/Paste error - fixed the code by adding back in the < before the xmlheader line.

It is probably a locale issue. Try a semicolon instead, so: {1;2}