Live data from Hacker News

Show HN: Regex Cheatsheet

ihateregex.io

81–90 of 135 posts

Re: Show HN: Regex Cheatsheet

#81
post #39
post #11

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.

AFAIK none of the TLDs allow for MX records on just the TLD

i.e. johndoe@com will never exist

Re: Show HN: Regex Cheatsheet

#83
post #62

One thing i've always missed from the Perl programming language is the regex operators. You could do: my $var='foo foo bar and more bar foo!!!'; if($var=~/(foo|bar)/g){ # does the variable contain foo or bar? print "foo! $1 removing foo..\n"; # remove our value.. $var=~s/$1//g; }

So did I: https://github.com/radiac/python-perl/

Re: Show HN: Regex Cheatsheet

#84

OK, these kinds of regex tools get posted quite often. I get it, regex is very confusing at first. And some of these use-cases result in rather complex expressions nobody should be forced to write from scratch (you are still remembering to write unit tests for them though, right?) But as someone who actually knows [some flavours of] regex fairly well, what I would really like, is a reference that covers all the subtl…

RE2 syntax[1] is a pretty good option to learn, because it's mostly a "lowest common denominator" - if it works in RE2, it should work in PCRE, Python, Javascript, etc. The reverse isn't true - there is a bunch of syntax that RE2 doesn't support by design, often to constrain performance bounds.

Emacs regexps are unfortunately their own weird beast - they handle parentheses differently than other regexp engines, because Emacs assumes that you'll be running regexps on Lisp code a lot and want to easily match parentheses. The best documentation on that syntax is (confusingly) in the Elisp reference manual: https://www.gnu.org/software/emacs/manual/html_node/elisp/Sy....

[1] https://github.com/google/re2/wiki/Syntax

Re: Show HN: Regex Cheatsheet

#85
post #46

Would be nice to have a regex for parsing HTML... grabs popcorn

Easy with a sufficiently powerful engine: https://stackoverflow.com/a/4234491 Relies on ?(DEFINE): http://p3rl.org/perlre#(DEFINE)

There is a good comment on that answer:

> To sum up: RegEx's are misnamed. I think it's a shame, but it won't change. Compatible 'RegEx' engines are not allowed to reject non-regular languages. They therefore cannot be implemented correctly with only Finte State Machines. The powerful concepts around computational classes do not apply. Use of RegEx's does not ensure O(n) execution time. The advantages of RegEx's are terse syntax and the implied domain of character recognition. To me, this is a slow moving train wreck, impossible to look away, but with horrible consequences unfolding

Re: Show HN: Regex Cheatsheet

#86

OK, these kinds of regex tools get posted quite often. I get it, regex is very confusing at first. And some of these use-cases result in rather complex expressions nobody should be forced to write from scratch (you are still remembering to write unit tests for them though, right?) But as someone who actually knows [some flavours of] regex fairly well, what I would really like, is a reference that covers all the subtl…

if you're on osx, the app Patterns is really good for testing regex, and also has quick references for a variety of regex 'engines' and also has decent matching explanations

https://krillapps.com/patterns/

Re: Show HN: Regex Cheatsheet

#90
post #68

OK, these kinds of regex tools get posted quite often. I get it, regex is very confusing at first. And some of these use-cases result in rather complex expressions nobody should be forced to write from scratch (you are still remembering to write unit tests for them though, right?) But as someone who actually knows [some flavours of] regex fairly well, what I would really like, is a reference that covers all the subtl…

Honestly, as a noob, this is one of the biggest reasons I have such a hard time deciding to learn regex. Python flavor would probably be different than PCRE, which is probably different than JS flavor. Even worse is that it might be too late to standardize all the regex flavors because there is already so much written in different regex flavors that it just costs too much for them to become obsolete in the future. Th…

> Honestly, as a noob, this is one of the biggest reasons I have such a hard time deciding to learn regex.

Clear your afternoon, and just learn it. Seriously, it takes a couple of hours at best and then - BOOM - you're done for the rest of your life.

Post reply on HN