I'll just leave this here.

Tools like the one at gskinner.com are handy, but they're definitely not a replacement for learning how regex works, and why.

Until one has a solid grasp of how regex works, I'd recommend staying away from the community contributions. Assuming something works without understanding how to read it sometimes leads to bad things happening.

I could probably have a field day in there, but I'll limit it to one example:

this regex from gkskinner.com promises to parse a URL

#<br />
# As per the included documentation:<br />
#<br />
# get all the elements in a URL:<br />
# group 1: schema<br />
# group 2: domain<br />
# group 3: path<br />
# group 4: file<br />
# group 5: queries, variables and achors<br />
<br />
^(?:(https?|ftp|file)://)?([a-z0-9-]+(?:\.[a-z0-9-]+)+)?(.*?)?(?:(\w+\.\w+)([^.]*))?$<br />

However there are several problems with it because it is not written to be compliant with the RFC spec. First, it doesn't take in to account the entire format of a URL. http://foo:bar@baz.com is a valid url, but it captures "foo:bar@" as the path of the URL, and "baz.com" as the file.

Similarly, using a port, such as: "http://baz.com:3000" - the regex matches :3000 as the path.

Because of the way this regex is designed, with each part being optional, it can't actually fail to match unless the input string contains a newline. Even if the input is a URL that is extremely broken.

Go get yourself a copy of O'Reilly's Mastering Regular Expressions. It covers not only Awk and Sed, but also PERL and PCRE and several others. Having a good healthy understanding of regex makes quite a few sysadmin tasks a LOT easier, especially with things like Puppet etc relying so heavily on them.