regular expression matching

Please post the patch, I'd like to at least see it.

With Backup and Migrate I don't think the risk is that large. I can see only exposing regex matching as an advanced option helping.

it would be very useful!
perfect for hunting down the typos in long texts,
especially when written by inexperienced users
please...

I second this - please post the patch! The ability to do a regex search would be SO useful

I'd be happy to use the patch. I would like to do a regex search, and then a string replace with a token value. Your patch would be 1/2 the work needed.

I'd love the patch. Could you send it to me? Rgds,
Ditto #7, if this had Regex *and* Tokens, it would be a killer module

As it is, very useful, because it lets me alter fields in commerce product types (other ones are typically restricted to nodes).

I gave it a shot,

please look at my diff.

The extra option allows to use regex and cancels whatever is in the prefix, suffix, exact match and case sensitive since we can put it all in the regexp.

* There is an extra fix there for a mistake in a var ($settings vs $options)

Patch in #8 works for me on a test website. We may end up using it in production as well as I've reviewed the patch and see no issues at this time.

This will need some additional work before release as preg_replace presents an arbitrary PHP execution attack surface via the "e" flag.

Here is a reroll of the patch against current -dev.

Originally I found this StackOverflow approach to striping the e modifier, which this patch is inspired from.
https://stackoverflow.com/q/7243073

Since php does not provide a way to disable the e modifier at runtime, the simplest solution I have opted to implement was to scan for the modifier and if found deny any vbo processing to occur until the enduser provides a regex that does not make use of the e modifier. For added UX I have amended the description of the advanced form item to note that "e" modifier is not permitted.

Although, this issue appears to only exist in PHP < 7.0, I have additionally I've added a check for the php version in the code.
http://php.net/manual/en/reference.pcre.pattern.modifiers.php

I believe the supplied patch now meets the needs of assuring additional security for the e modifier. Additional feedback from the community, bot(s), or the maintainer is appreciated.

This looks like a sound solution to me.

Committed to the dev branch. I added in a permission to control access to the regular expression option as there is a lot of potential to nuke a site with this capability. Thanks to all that contributed.