Hacker News Reader

Comment by leeoniya | Hacker News Reader

just decided to randomly click a chapter. in 12.1 wouldn't

^[0-9]+|[A-Z]+$ in fact need to be written as

^([0-9]+|[A-Z]+)$ or non-capturing

^(?:[0-9]+|[A-Z]+)$

i doubt the intent was to alternate NL/EOL assertion. seems like a novice oversight and does not instill confidence in the rest of the material.

or am i missing something?

View on HN

Hmm, well the book is being written so there's potential for some errors, but I believe you are wrong here. You're confusing match with search semantics. Your above works because by default Regetron searches. If you turn on match it doesn't match your proposed test below. Try this:

http://codepad.org/uPpwKPJS

Notice when you turn on !match it doesn't find your test.

Also, keep in mind that this is just introducing the concept of alternating. Captures are covered later.

I agree with the GP --

http://codepad.org/YmsaEtJS

Great, another example of regex engines not doing anything you tell them. I'll look at changing it but () isn't going to work there it has to be taught later.

the solution seems pretty easy. simply leave out the beginning/end-of-line assertions. [0-9]+|[A-Z]+ would suffice for that example. i agree that introducing capture groups IS too early, but you can add the parentheses without mentioning capture groups, even if they do capture. grouping still has great value as a precedence indicator which is taught in gradeschool arithmetic.

it's rather unfortunate that the syntax to capture is "(" while the less complex no-capture is "(?:", i'm not sure who thought that through, but here we are.

Yes, I hate that (?:) syntax. Who the hell thought that crap up.

But, I will point out that you attributed the error to NL/EOL assertion, when actually it was order of precedence of | being greater than $ and ^. It's a simple nearly 1-2 character mistake, not a "novice" mistake that discredits the entire book.

yeah i apologize, perhaps i was a bit harsh. i did understand what the issue was and never claimed that it was the newline/EOL assertion itself. i said that your newline/EOL assertion is being treated as PART of the alteration, which is exactly what happens - yes because of pipe's higher operator precedence when no explicit grouping is defined.

novice or not though, 2 misplaced chars in a regex can make the diff between a security feature and a security hole, in this case matching a plethora of inject-able, potentially malicious characters which appear nowhere in the regex, not even as a wildcard ".", i would never make the claim that a 2-char mistake which matches this far beyond its intent is a minor oversight in a real-world, public facing application - and isn't that the ultimate goal?

the only issue in the context of a book for a regex beginner is that the regex gives the appearance of newline/EOL assertion hugging an alteration, but does something quite different. removing those assertions would clear things up for the better.

Ok, both of you are wrong. It's got nothing to do with EOL, it's the parse order of precedence of | which makes it parse as (or (^[0-9]+) ([A-Z]+$)), but I was reading it as ($ (^ (or ([0-9]+) ([A-Z]+)))). Now I know why I should change it rather than I just suck.

I'm not exactly sure how you thought I was interpreting it -- that's exactly how I understood the original comment and I still think that was leeoniya's point.

The point is not to have the best or most efficient regex expression, but rather to do the exercises and to highlight by this process misconceptions you may have about how the regex engine operates.

You enter what is given, you run it, see what the console returns, ponder about the implications for a few minutes and then scream "aha!"

What do you expect ^[0-9]+|[A-Z]+$ to return when matched against the various lines? What does it actually return? What conclusions do you draw from that little experiment?

unfortunately this is not an efficiency optimization. the intent appears to be to match EITHER all-alpha OR all-numeric strings.

the regex, as given, would match both "&()ABC" and "5673%$^#" and "123ABC" but NOT "ABC123"

what should be a simple concept is defeated and confusion ensues. the correct formulation should have been ^[0-9]+$|^[A-Z]+$ or (judging from the example input and output samples) [0-9]+|[A-Z]+

Uh, no, the intent is not to match all-alpha or all-numeric strings. It's to search for all alpha or all numeric. As I mentioned above, you're confusing search with match semantics.

Reply on news.ycombinator.com