Inconsistent Behavior of REs

[greyorm]

Earlier today, I was running a Search & Replace in Textpad 5.2.0, trying to delete a significant amount of text between the <style> tags on multiple webpages. I was using the trick where \n is replaced with a unique textual indicator, making the entire file into one long line. The Regular Expressions checkbox was checked, and I tried with Posix compatibility both checked and unchecked.

The issue is, when using <style type="text/css">[[:print:]]*</style> Textpad states it can not find the specified string. If I remove the ending </style> tag, it finds the beginning of the expression, but only a few hundred characters until it just stops at a space (and not the first space, either).

I found this strange because I used the same RE to remove a significant amount of javascript between two <script> tags just prior to this without any issues whatsoever.

After looking at the forums, I also tried another method: <style type="text/css">.*</style> which caused Textpad to completely crash just by invoking Find Next. However, <style type="text/css">.* lets Find Next run fine, selecting all the text from the desired starting point right to the end of the file without a crash.

I eventually wrote a macro and ran it on each file manually, which was rather a pain and took much more time than I'd wanted to put into the project. But I'm at a loss. I thought I'd finally gotten the hang of REs, but apparently not?

I find myself wanting to know why the former RE isn't working, given that it seems as though it should, and why the latter would be causing a crash. Anyone have any ideas, see any mistakes in the REs, or have an explanation for the weird behavior?

[MudGuard]

The issue is, when using <style type="text/css">[[:print:]]*</style> Textpad states it can not find the specified string. If I remove the ending </style> tag, it finds the beginning of the expression, but only a few hundred characters until it just stops at a space (and not the first space, either).

Are you sure it stopped at a space? A normal space? Or maybe at some character that only looks like a normal space (e.g. a non-breaking space)?

What happens if you use .* instead of the [[:print:]]* ?

And also of interest: does it happen with the current version of Textpad as well?

[Bob Hansen]

Can you provide the text that is being searched for us to do tests on? If not the text, then maybe a link to it?

MudGuard - It sounds to me like he subsequently did use .* but that just crashed with Find Next as long as </style> was included.

[greyorm]

MudGuard,

As far as I know, it was a normal space. I considered that it might have been a space with some kind of hidden attribute, but I could see no way to tell if it was...well, whatever else it might have been.

Also, yes, I tried .* (which resulted in a crash when </style> was included after *, and worked fine when it was left off). Apologies if that was unclear.

I had not tried it with the current version of TextPad.

Bob,

I can possibly do so. As mentioned, I had already cut all the text using a macro, and decided to post about the issue only on reflection. Realized then I should have kept a copy of the bad file, but hindsight.

I still may be able to retrieve a copy of one of the unaltered files. Assuming I can, the HTML is fairly long, so how would you like me to provide it: just post it here or by some other method?

(I'm also assuming this means it was not a mistake on my part with the construction of the RE?)

[Bob Hansen]

(I'm also assuming this means it was not a mistake on my part with the construction of the RE?)

Without testing your expressions on the same text, it is not possible to identify the cause of the problem yet.

You can paste the data here (Disable HTTP), or you can provice a link so we can grab the source code.

[greyorm]

I have placed a copy of one of the files I was working with here: I had pulled them from archive.org after a server crash caused much of the affected site's data to be lost and was stripping them down to bare HTML. Note that the repeating junk bit 3NL4 throughout the file is my placeholder for \n so I could work with the file as a single line (then Search & Replace it back to normal afterwards).

I have run all the following commands on this file, and re-verified the results following:

<!\-\- SOME [[:print:]]*</script> : correctly removes the block of javascript at the bottom

<style type="text/css">[[:print:]]* : selects only the following, stopping on the 4 -- <style type="text/css">/**3NL4 * Highlight style classes3NL4 * .a background color3NL4 * .b underline3NL4 * .c underline + font color3NL4 */3NL43NL4@media screen{3NL4em.diigoHighlight {3NL4

(Some further fooling around revealed that the "space" after the 4 is actually a tab and is causing the issue with the above RE not selecting all the desired text. My bad, there, with tab not being a printable character. Still curious about the crash, though.)

<style type="text/css">[[:print:]]*</style> : reports "Cannot find regular expression."

<style type="text/css">.* : selects everything in the file starting from <style type="text/css"> to the end

<style type="text/css">.*</style> : causes the program to crash, reporting "Unexpected and unrecoverable error. Would you like to save a diagnostic file?"

[Bob Hansen]

Thanks for the example script. I think I have a solution for you.

OK, three steps to find the style block:

1. Replace all "\n" with a unique value :3NL4
2. Replace all "</style>" strings with a single unique char: ~
3. Find this RegEx: <style type="text/css">.[^~]*~

When done, replace original chars.
4. Replace "~" with "</style>"
5. Replace "3NL4" with "\n"

Explanation:
1 TextPad's RegEx cannot handle multiple lines, so we replace \n with something else.
2. TextPad's RegEx is always greedy. But we can fool this by looking for all chars except the one we want to end at. We cannot put a string in the [^] frame, so we need to use a single char. That is why we replace </style> with the tilde, a single character that allows us to do .[^~]*~

You have already overcome the problem where "space"s are not true spaces, so you should be good to go now?

Use the following settings:
-----------------------------------------
[X] Regular expression
Find Next
-----------------------------------------
Configure | Preferences | Editor
[X] Use POSIX regular expression syntax
-----------------------------------------

[greyorm]

Yep, that works! Thank you for the help and explanation.

Still curious why it would crash under the one RE. Any idea? (Is there something I should avoid using in building an RE that causes it?)

[paleolith]

OK, this was a month ago, but ... since no one recognizes the crash as a known and documented problem, and assuming you are using the lastest version of TextPad, then you should report it using the feedback form:

http://www.textpad.com/support/textpad.php

Make it clear in the report that what you are reporting is just the crash.

Edward

[greyorm]

As noted, I was using version 5.2.0. I've just upgraded to the latest version and tested the issue: it does not crash, though it does toss out an error: "Recursion too deep; stack overflowed." and then the program resumes normal operation.

[paleolith]

Personally I would still file a report. It's been said here that TextPad is using a very old RegEx engine, so they may not be able to do much about this in the current version. However, since they've put a newer engine in WildEdit, they are probably weighing whether to do the same in TextPad. The more reports they get of real problems, like this, the more likely they are to implement a real change.

Edward

[greyorm]

Fair enough. I'll file a report then; can't hurt.