I once wrote a website (http://regexone.com) to help people learn regular expressions using practical examples -- maybe you would like to give that a try and see if it helps you in understanding the different regexes a bit more?
I just went through all the examples, that was awesome! Best tutorial I've seen yet. With this and debuggex, I should be all set to parse HTML with regexes (kidding).
By the way, could someone explain this to me - do regexes match a string if a part of a string matches the regex, or if the whole string does?
For example, this regex "([+|-]* )(\d+[,|.]* )(\d+)(\.)?(e)?(\d+)" (intended to match decimal/scientific numbers - see http://regexone.com/example/0) matches "720p" on regexone, but fails to match on debuggex. So it seems like it varies depending on some configuration - is that right?
That regex doesn't match 720p on regexone (and shouldn't - it has required spaces in it). You're getting a tick for the bottom item because it's not supposed to match that case.
As for your question, it generally depends how they're called - eg. in Python's re module, whether you call search() or match(). You can force a regex to match the entire string by adding ^ and $.
Used your site a few months ago and have been recommending it to everyone since! Can I make a request for "best Solutions" & possibly more exercises? Its been the best resource I've found for getting the basics down, thanks!
Just two comments:
* when having cases that should match and other that not, It would be ok to differentiate them
* in some lessons it would be ok to force the full string to be matched. If not it's too easy to write i.e. file in http://regexone.com/lesson/8? and pass to the next one.
I was just taking a look to it as I'd like some of my non-technical staff to understand how regex works - they need it for Google Analytics filters - and it looks wonderful.
Yes, the intention was to help solve those cases where you are staring at your screen because you don't know where the match went wrong.
I'm thinking of doing some tutorials geared towards teaching students in grade school how to use them. I think a visual representation would help significantly.
Seconded - it's superb. Having the example button for new users of regexes or people who haven't used one in a while is an excellent addition, as are the diagrams.
I find it sort of sad that several people have responded by linking to their preferred (but clearly inferior) Regex pages, which detracts from the accomplishment of this one.
I understand RegEx, but am (almost) completely unable to read it. For me, this site it perfect.
The way I learned RegEx was simply spending 2 work days writing a parser with it. I think the problem is that there is a moment when RegEx suddenly makes sense, and you cannot understand how anyone can be confused by it (even when you yourself were confused just 5 minutes ago).
Many other algorithms have exponential edge cases. This can open yourself to DoS'ing if you accept regular expressions from the user (e.g. a search feature.)
No. While you are correct a DFA is far superior for parsing this specific subset of javascript regex, it does in no way make it ideal for debugging purposes.
1) In the user's program the regex is not going to be run on a dfa (since we are talking about the javascript variation which has back references). It makes more sense to warn the user about bad performance, than making them believe they are safe.
2) A debugger has to be true to the input. If the user wants to debug (a) it doesn't help that the debugger just casually transforms it into a*. That wouldn't make the diagrams fun at all.
3) It is entirely possible that in the future, the author wants to expand the awesome tool to a larger subset of javascript regex. This would probably make it break out of the finite automa space.
I do however agree that it's a pitty how many good regular expressions are run on stupid backtracking systems out there.
Javascript doesn't mandate that this regular expression be slow. In fact, in Safari and Firefox on OSX this regular expression runs fine. Chrome OSX fails but I remember it running fine in Linux yesterday (but I might be wrong.)
1) Back references do not mean you need to have exponential edge cases for vanilla REs
2) There is no one true way to execute an RE. There are good ways and bad ways, though.
3) The Thompson algorithm does not preclude non-regular extensions.
Anyway, just wanted to add the rsc link to the discussion :)
Sorry for the delayed response. Spent all day yesterday responding to feedback. The reason this crashes is due to the internal javascript engine.
In order to ensure that my engine (I simulate a kind of NFA) matches what javascript's engine matches, every time I match on my engine, I also try to exact match using javascript's engine. Unfortunately, javascript's engine always uses backtracking, even when it doesn't need to. Obviously this code should have been turned off for production, and I'll fix it on the next push.
To replicate the crash on your own, try typing:
'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab'.match(/^(a)$/) in your console.
Interesting - it seems some browsers dont have this as an exponential edge case and indeed in those yours doesn't execute exponentially (I guess I got mixed up when testing.)
Anyway I dont consider it a "bug" or anything, just wanted to bring up the rsc paper for discussion :) Keep up the good work!
As a long time Rubular user, I will be switching to Debuggex.
It just feels right to me. It explains your regex to you, which, in my mind, is a much better way to debug a regex than to supply a large set of test strings.
Well, you didn't use the same regular expression. If you use the same one the matching is the same. Here is the link of tubular with the same expression than debuggex: http://rubular.com/r/rMu0nAnJai
Important caveat: it makes use of a hidden Java applet -- so that it can supports the somewhat larger Java regex syntax, doesn't send your data anywhere else for matching, and can hook into the string-probing to animate the process. So dig out whatever browser you use for Java applets (if you still have one) to test.
Regarding the animation, click the 'animate?' link to show the animation step/speed controls. For example, you can watch the regex that tests whether a number is prime (by failing) or composite (by succeeding) via these two animations:
I really want to get rid of the applet requirement; I might someday cross-compile the JDK7 regex support to JS so that the full syntax and animation can still be supported, without an applet.
Generally I try these sorts of things out on a small but non-trivial example. Unfortunately it failed, so while this regex debugger shows a great deal of potential, there is still a bit more work to be done. My inputs:
Regex: TVo[12].\d.* [Aa] ..[^k]
Test string: TVo1-0:01.0-1:01.0 A Nashville
Very nice. I'd recommend making the text to match field a text area and doing line based matches.
When I need to haul out the big guns, I load up RegexBuddy in a Wine bottle and dump a screenfull of text into it along with the regex to figure out where I went wrong.
They have a very different way of visualizing the step by step, but both are great tools.
The text to match field is a text area; it will auto-expand as you type into it.
However, only exact matches are supported for the first release. I wanted to get user feedback before I built any more features. I think I have an intuitive way to visualize findAll() type matches.
This is really cool! One thing that would be really awesome would be if you added a way to switch between disambiguation strategies. At the moment, it seems like the default strategy is greedy parsing (i.e. the "Perl way"). For instance, when matching the string "ab" against (ab)(b?) the first group matches "a" while the second matches "b". With the POSIX strategy, the first group will match "ab" and the second will match the empty string.
I think these subtle differences leads to a lot of confusion when users are not aware that the underlying implementation is different from what they are used to.
Not bad. Have you thought about supporting a much larger string area? The re editor in Slickedit lets me paste multiple lines of text and see what parts get matched by the regex which is super useful for searching and replacing code and also very useful for multi-line matches.
Suggestions; the regex reference could use a distinguishing feature such as a subtle light grey background and/or a line seperating it along with more whitespace.
Also, the boxes seem arbitrarily placed. I realize one is centered, and the others take up the remaining space on the next "line", but perhaps you could create better visual boundaries or something.
Lastly, apologies, but maybe the font Lato looks nice on your setup, but its rather jaggedy/unappealing on windows.
The regex reference is only temporarily there. It'll eventually be replaced by a much better feature which is in the pipeline. I'll play around with the css to make it better.
I've played around with the positioning a bit, and it definitely needs iteration. However, an upcoming ui change will drastically change the demands on the ui, so it doesn't make sense to optimize that yet.
I'll replace the Lato font. I agree it looks terrible on windows.
This is really awesome, and it's immediately going into my batbelt bookmark folder.
One quick UI note: The reference table is much easier to read if the lines are left-aligned. With centering and two columns, it's hard to tell at first which descriptions the escape sequences belong to.
This makes regex fun, I could actually see myself relying on it more. Not sure if I'm not writing them every day if I'll remember a year from now what \dd does but now I have a good site to go to to remember again. Nice site.
How would you recommend generating fail string? The space of failing strings is really large. From my discussions with users, they usually have a specific failed string and they want to see why it doesn't work.
That is a good visualization. However, it doesn't let you debug if there is a problem with matching a string. That was the explicit goal in building Debuggex.
Linting is a planned feature for a future release.
for a desktop regex "debugger" app, I've been using Edi Weitz's wonderful Regex Coach - http://www.weitz.de/regex-coach/ (Windows only version, written in LispWorks)
It is way better than the other ones for a variety of reasons. A big one for me being the ability to directly share the URL of an example.
I'm sure they can do better: next please provide us the ability to use a tiny URL directly from within the domain (i.e. do not force me to lamely go to bit.ly or other non-sense).
Imagine walking from the start to the end along the railroad diagram. Every time you come to a split in the road, you choose a random one. Every time you come to a character set, you choose something random inside there. That's all there is to it.
Unfortunately if you don't "understand" RegEx it won't help much. It is more for people who already have it down.
For me I am still stuck in copy/paste land. I could never get my head around the "logic" of RegEx, it just seems completely random and arbitrary.
Plus they re-use the same characters but have multiple meanings (e.g. ^ for NOT and for START).