4 ms·

This article is kind of a bait and switch actually. It first states: >we want to match Tarzan except when this exact word is in double-quotes and so the reade

This article is kind of a bait and switch actually. It first states: >we want to match Tarzan except when this exact word is in double-quotes and so the reader might start thinking of ways to "match" this. The author then starts to mention ways to do this, but at the end, their trick is actually to not "match" it, but to remember it in a group. This will not match what the author says it will match, because if you do regex.test(string) it will return true when "Tarzan" appears, because it is in the or statement. It appears the author is very good at storying-telling though.

bmn__ 5y ago
Is that a bug? Certainly feels like one. Try it with software that does not blow goat dicks, and it does not disappoint: $ perl -E'say q("Tarzan") =~ /"Tarzan"(*SKIP)(?!)|Tarzan/ ' $ perl -E'say q(Tarzan) =~ /"Tarzan"(*SKIP)(?!)|Tarzan/ ' 1 $ printf '"Tarzan"' | pcre2grep '"Tarzan"(*SKIP)(?!)|Tarzan' $ printf 'Tarzan' | pcre2grep '"Tarzan"(*SKIP)(?!)|Tarzan' Tarzan
ticklemyelmo 5y ago
It wasn't really phrased that way, but that was really the core insight of the piece -- if you take a step back and look at the problem from the context of the code running the regex instead of within the regex itself, it's much simpler. Use all the tools at hand to get the job done.
ehsankia 5y ago
In the very first section (albeit after from introduction, but still before the Tarzan example you show), it clearly states the limitations: > Before we proceed, I should point out some limitations of the technique: The author clearly states you may have to add one or two extra line of code, in your case regex.test(string) may become `regex.match(string).group(1).length` > 0 or something along those lines. The author explicitly states: > so it will not work in a non-programming environment, such as a text editor's search-and-replace function or a grep command. But in a programming environment, I will choose to have one more line of code over the extremely hard to read alternative regexes.

bmn__ 5y ago

Is that a bug? Certainly feels like one. Try it with software that does not blow goat dicks, and it does not disappoint: $ perl -E'say q("Tarzan") =~ /"Tarzan"(*SKIP)(?!)|Tarzan/ ' $ perl -E'say q(Tarzan) =~ /"Tarzan"(*SKIP)(?!)|Tarzan/ ' 1 $ printf '"Tarzan"' | pcre2grep '"Tarzan"(*SKIP)(?!)|Tarzan' $ printf 'Tarzan' | pcre2grep '"Tarzan"(*SKIP)(?!)|Tarzan' Tarzan

ticklemyelmo 5y ago

It wasn't really phrased that way, but that was really the core insight of the piece -- if you take a step back and look at the problem from the context of the code running the regex instead of within the regex itself, it's much simpler. Use all the tools at hand to get the job done.

ehsankia 5y ago

In the very first section (albeit after from introduction, but still before the Tarzan example you show), it clearly states the limitations: > Before we proceed, I should point out some limitations of the technique: The author clearly states you may have to add one or two extra line of code, in your case regex.test(string) may become `regex.match(string).group(1).length` > 0 or something along those lines. The author explicitly states: > so it will not work in a non-programming environment, such as a text editor's search-and-replace function or a grep command. But in a programming environment, I will choose to have one more line of code over the extremely hard to read alternative regexes.