3 ms·

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

by zedshaw 15y ago

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 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.

spicyj 15y ago
I agree with the GP -- http://codepad.org/YmsaEtJS http://codepad.org/YmsaEtJS
- zedshaw 15y ago
  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.
  - leeoniya 15y ago
    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.
    - zedshaw 15y ago
      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.
      - leeoniya 15y ago
        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.
- zedshaw 15y ago
  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.
  - spicyj 15y ago
    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.

by zedshaw 15y ago

spicyj 15y ago

I agree with the GP -- http://codepad.org/YmsaEtJS http://codepad.org/YmsaEtJS

zedshaw 15y ago
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.
- leeoniya 15y ago
  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.
  - zedshaw 15y ago
    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.
    - leeoniya 15y ago
      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.
zedshaw 15y ago
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.
- spicyj 15y ago
  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.