Learn Regex the Easy Way
github.com
github.com
Each one seems to have slightly different syntax, require different characters to be escaped, has different defaults (is global search enabled by default? Multiline? What about case sensitivity?), some don't support certain lookarounds, how does grouping work, and so on.
[1] http://www.regular-expressions.info/lookaround.html [2] http://www.regular-expressions.info/refadv.html
https://msdn.microsoft.com/en-us/library/2k3te2cs(v=vs.110)....
from the qed/ed editor idiom g/re/p, where re stands for a regular expression, to Globally search for the Regular Expression and Print the lines containing matches to it
In fact, grep predates the GNU project by almost a decade.
Also, it's the first time I hear about "GNU" regexps.
Source: http://pubs.opengroup.org/onlinepubs/7908799/xbd/re.html#tag...
\{,m\} is a (pretty obscure) GNU extensions.
Another thing is escaping: when you write sed regexs in a bash script you have to use slightly different escaping sequences sometimes...
> remembering the exact syntax of each of the different common regex engines
I just know one really well and rely on getting it wrong for the others: guess, test, revise, repeat.
Some of the look arounds might be too powerful to do in some engines so it would not always work, but it would still be quite useful if it just handled the differences in escaping, specifying modes like case insensitivity or multiline matching, and referencing match groups in replacements.
For example, if you do ListFiles[folder=~/Downloads] -> FilterString[field=filename, regex=\.pdf$], it will parse the regex, verify that it only uses features which are available in Spotlight's query syntax (roughly, a glob with slightly funny syntax), and rewrite that adjacent pair of operations into a single API call behind the scenes:
kMDItemFSName LIKE[c] "*.pdf"
A lot of the work in deciding if a translation is possible is in identifying if something is good enough, e.g., SQLite can't do case-insensitive search (in general), but if your regex happens to be /([0-9]+)/ then case-sensitive search will work just fine. Fortunately, for Strukt, if a conversion is impossible, I can just run the operations as written: it's much slower, but still correct.
I've thought about breaking this part of Strukt off into a tool just for regex editing, but that always seemed rather esoteric. Would there be any use or demand for that, do you think?
It's a real pain, especially when you want a quick one-off regex. In that case the learning curve changes the economics of what the right tool is for the job. Often I'll just end up writing a program using a tool I already know, even though I'm aware that it's a less efficient choice—at least its inefficiency is predictable. Of course if you do that enough times then you've spent more than the original learning curve would have cost! I have done this in painfully many contexts. Regexes are an obvious case, probably because they're so obviously doing the same thing, just differently enough to waste your time.
Some people actually like searching for and paging through documentation to learn how, e.g., regex format X does character escaping. And they tend to remember such things, too. I don't and don't.
This is a very big issue and one I recently faced in the workplace. Needed a script to parse some log files to generate CSV reports for the business users. I knew jq (https://stedolan.github.io/jq/) and hence was able to write less than 10 lines of jq to do it combined with some preprocessing using sed.
I then realised that NOBODY on the team knew jq apart from me and I had to rewrite it in Python which took me 4 days to do correctly and handle everything that jq did for me.
* http://www.regular-expressions.info/tools.html
nooks and crannies of pretty much every major flavor and variant, prepared as an easy reference.
It explains what each character does just by hovering over a regex. Best tool to learn or to fine tune your regular expression (with testing included).
You can even step through the matching process and see how your matches are made
It will also do things like warn you if you use named groups if your selected language doesn't support them, and the "Use" dropdown won't provide that option.
I really wish it wasn't Windows only.
I generally use https://regex101.com for its display of matched groups (when I'm dealing with complex groups and/or replacement backreferences), and http://regexstorm.net/tester when I specifically need to check a regex that will be running in .NET or Powershell.
The book is worth it's price if only for chapter 1, definitely seconding this recommendation.
This site is a very nice summary of regexp syntax and is written well -- but it's missing two crucial pieces that help people learn: Examples and exercises. Without practice, there's no way that people can remember the syntax.
URL: ^(((http|https|ftp):\/\/)?([[a-zA-Z0-9]\-\.])+(\.)([[a-zA-Z0-9]]){2,4}([[a-zA-Z0-9]\/+=%&_\.~?\-]*))*$
Has anyone encountered this behavior? Couldn't find anything on the internet; maybe it's just my computer?
I'm not enough of a history boffin to know how Microsoft came to support it differently (perhaps something from the Netbios and NT era). At this point in time though, I don't see either party changing their default validations to agree on a single definition.
Edit: If you're curious, this is the first commit that appears to be the first glibc commit limiting dashes at the end of URLS https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa0bc.... I don't know about BSD libc, or windows however.
Of course that's assuming you know the right file, which is often the harder problem.
If there are people running OSX or Linux that want Windows downloads, or someone is behind a captive portal or proxy (like squid), they probably won't be able to reach it anymore.
If you have a real problem with bots, I'd look at what IPs they are coming from, and how often they try to connect. Something like IP blacklisting, or fail2ban might work for your use case.
It's a step-by-step interactive site. One of the best educational programming sites I've been to.
Testing Regex is a lot easier when you have the fundamentals down and there's a million resources to test Regex.
i.e. Encountering them here, there and everywhere. Then one day realising you have a good knowledge of the subject without ever having set out to learn it.
Agree with others in that RegexBuddy is indispensable for a windows dev learning this magic stuff.
Some useful and interesting regex developments coming in the next version of JavaScript. Support for international text and (bleh) emoji incoming.
Seriously. Test every non-trivial regex with something like this, you'll probably be surprised at how permissive most regexes are.
Regexes are great. They're super-concise and perform amazingly well. But they're one of the biggest footguns I know of. Treat them as such and you'll probably do fine.
---
[1] for instance, the URL regex they use is incorrect, and it's super obvious when you plug it into that site:
^(((http|https|ftp):\/\/)?([[a-zA-Z0-9]\-\.])+(\.)([[a-zA-Z0-9]]){2,4}([[a-zA-Z0-9]\/+=%&_\.~?\-]*))*$
It also has first-class grammars, so you're less tempted to reach for regex when something more powerful would help.
I'm afraid not much has been improved since then.
This is not a good learning source.
These introduces the metacharacters gradually, using a task-based approach. We start by finding street addresses, per https://xkcd.com/208/.
[1] http://mackerron.com/text/text-slides.pdf (page 19 onwards) with supporting resources at http://mackerron.com/text/