Re^2: Why do these regex variants behave as they do?

/me slaps head;
...wishes he could award multiple ++ to both BrowserUk and AnomalousMonk for clear, concise and brilliantly on-target replies.

I had played with a char class at some point in this evolution... and didn't quite nail it (didn't event come close?). But your answers made it clear that one "right" (YMMV) approach with a class is:

#4 Non-capture (grouping) paren-pair contains the capture parens which
+ use a char_class
if ( $string4 =~ />(?:([\s|\w]+))(?:<\/td>)/m ) {
    say "regex 4: $1";
}
[download]

Again, thanks for spotting my blind-spots!

Comment on Re^2: Why do these regex variants behave as they do? Download Code

Replies are listed 'Best First'.
Re^3: Why do these regex variants behave as they do? by AnomalousMonk (Archbishop) on Oct 03, 2011 at 01:23 UTC
`if ( $string4 =~ />(?:([\s\|\w]+))(?:<\/td>)/m ) { ... }` [download] In `(?:([\s\|\w]+))` the '\|' (pipe) character in the character set is taken literally (i.e., the set matches any whitespace, word or '\|' character) and so is probably not what you intend! Also, the non-capturing grouping is redundant: `([\s\w]+)` should work just as well. Further, the `(?:<\/td>)` at the end (in which the non-capturing grouping is also redundant) requires a positive match on this sequence of characters, whereas in previous code this was a `(?!<\/td>)` zero-width, negative look-ahead assertion; don't know if this difference was intended or not (Update: although on second thought it probably was intended since it was the negative look-ahead that led to the missing-final-character puzzlement).	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Why do these regex variants behave as they do?
by AnomalousMonk (Archbishop) on Oct 03, 2011 at 01:23 UTC

if ( $string4 =~ />(?:([\s|\w]+))(?:<\/td>)/m ) { ... }
[download]

In (?:([\s|\w]+)) the '|' (pipe) character in the character set is taken literally (i.e., the set matches any whitespace, word or '|' character) and so is probably not what you intend! Also, the non-capturing grouping is redundant: ([\s\w]+) should work just as well. Further, the (?:<\/td>) at the end (in which the non-capturing grouping is also redundant) requires a positive match on this sequence of characters, whereas in previous code this was a (?!<\/td>) zero-width, negative look-ahead assertion; don't know if this difference was intended or not (Update: although on second thought it probably was intended since it was the negative look-ahead that led to the missing-final-character puzzlement).

[reply]
[d/l]
[select]