3 ms·

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]+

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?

mekoka 15y ago
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?
- leeoniya 15y ago
  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]+
  - zedshaw 15y ago
    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.
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.

mekoka 15y ago

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?

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

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.