Live data from Hacker News

Show HN: Regex Cheatsheet

ihateregex.io

91–100 of 135 posts

Re: Show HN: Regex Cheatsheet

#91
post #90
post #68

Earlier quoted context omitted.

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.

> you're done for the rest of your life.

If that were so easy then I don't think much of these cheatsheets would exist.

Re: Show HN: Regex Cheatsheet

#92
post #72

Earlier quoted context omitted.

Can you explain the problem further?

please see my reply to @gizmo686

I guess I don't understand. Mind throwing up an example with multiple test strings on regex101.com ? I'd like to take a look and see if I can make a regex which does what you want.

So if you could write the examples there, and then a description like you would tell your mom of what you want I'll see what I can do.

Re: Show HN: Regex Cheatsheet

#94
post #81
post #39

Earlier quoted context omitted.

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

What about things like root@localhost?

Re: Show HN: Regex Cheatsheet

#95
Nice work on this!

Something subtle, but I quite loved the email regex is, IMHO, close to perfect: \S+@\S+\.\S+

Because the "perfect" one is just absurd, and no one realizes it's going to be so fucking absurd until they start getting support cases and then go read something like this: https://stackoverflow.com/a/201378/931209

> If you want to get fancy and pedantic, implement a complete state engine. A regular expression can only act as a rudimentary filter. The problem with regular expressions is that telling someone that their perfectly valid e-mail address is invalid (a false positive) because your regular expression can't handle it is just rude and impolite from the user's perspective.

Re: Show HN: Regex Cheatsheet

#96

Nice work on this! Something subtle, but I quite loved the email regex is, IMHO, close to perfect: \S+@\S+\.\S+ Because the "perfect" one is just absurd, and no one realizes it's going to be so fucking absurd until they start getting support cases and then go read something like this: https://stackoverflow.com/a/201378/931209 > If you want to get fancy and pedantic, implement a complete state engine. A regular expres…

Even this regexp has false positives.

The `ai` ccTLD ran their own mail server at the root, so an address like `a@ai` was a valid email address.

They serve a website at the tld root: http://ai./

Re: Show HN: Regex Cheatsheet

#100

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…

By coincidence, I found this link a bit earlier today. It tries to avoid flavors and exotic syntax.

https://rexegg.com/regex-quickstart.html

Post reply on HN