51–60 of 135 posts
Would be nice to have a regex for parsing HTML... grabs popcorn
With subroutines and recursive patterns I think you could do something parsing valid HTML. Your sanity won't be left intact tho.
[1] http://www.drregex.com/2018/11/how-to-match-b-c-where-abc-be...
This is really cool! 2 points: 1. it fiddled with my back button which is a bit annoying 2. a better email sample is ^[^@]+@[^@]+\.[^@]+$ which removes the 2 ampersands problem.
Even that is wrong because you can have privately owned TLDs (I forget what they're technically called) like .google So sundar.pichai@google is technically a valid address (whether .google has any MX records is another matter) Regex shouldn't really be used for email addresses anyway because the only reliable way to authenticate an email address is to literally send an email to that address.
I use regex a lot but deliberately keep it simple. One thing that confounded me often was positive and negative look-arounds. I always got the expressions mixed up, until I just put the expressions into a table like this... look-behind | look-ahead ------------------------------------ positive (? It's not hard, but for whatever reason my brain had trouble remembering the usage because every time I looked it up, each…
I have a secret hobby of answering python + regex questions on stackoverflow with pure python.
in the cheatsheet is false. (https://regexr.com/4tc48)
`.` can match any character except linebreaks (including whitespace)
Very cool! The site that worked best for me to learn regex was https://regexcrossword.com/ - after solving my way through all of them (I got really hooked when I discovered the site) I found I was alright at regex.
Nobody pointed it out, but there's also https://regexr.com/ It's how I learned regex years ago, and I still use it today to test/build more complex patterns.
Nobody pointed it out, but there's also https://regexr.com/ It's how I learned regex years ago, and I still use it today to test/build more complex patterns.
Nobody pointed it out, but there's also https://regexr.com/ It's how I learned regex years ago, and I still use it today to test/build more complex patterns.
My go-to is https://regex101.com/
But as someone who actually knows [some flavours of] regex fairly well, what I would really like, is a reference that covers all the subtle differences between the various regex engines, along with community-managed documentation (perhaps wiki pages) of which applications & API versions use which flavour of regex.
For example, the other day I wanted to run a find on my NAS. I needed to use a regex, but the Busybox version of find doesn't support the iregex option, so all expressions are case-sensitive. With some googling, I was able to find out that the default regex type is Emacs, but I wasn't able to find either a good reference for exactly what Emacs regex does and doesn't support, nor any information about how to set the "i" flag. In the end I had to manually convert every character into a class (like [aA] for "a") which was tedious, but quicker than trying to find a better solution or resorting to grep.
A related, annoyingly common pattern is that the documentation for `find` states that `--regex` specifies a regex, but it does not state which flavour of regex. The documentation for certain versions of `find`, which support alternative engines, note that the default is Emacs. From this I was able to infer (perhaps wrongly) that the Busybox `find` uses Emacs-flavoured regex, but ultimate I still had to resort to some trial-and-error. This problem is all too common in API documentation.