
Laurent_R
Veteran
/ Moderator
Dec 1, 2015, 2:38 PM
Post #13 of 14
(19757 views)
|
Re: [BillKSmith] postive and negative lookahead assertions
[In reply to]
|
Can't Post
|
|
Hi Bill, I think there must be a misunderstanding here. Although I was answering to your post, it did not mean in any way that I disagreed with it. I only begged to explain the reason why your code succeeded and the OP's code did not.
The issue of greediness never arises because there are no greedy (or non-greedy) operators in the match. Agreed, the issue of greediness never arises in your code, since you have no quantifier at all in your matching part, and that's why it works easily (and, BTW, I fully agree that's the way it should be). But my whole point since the beginning was that the OP's code:
perl -ne 'print if /(line.*)(?!.*fox)/' text.txt did not work as expected because of the ".*" within the match subexpression, which gave the regex engine an opportunity to find a match not impaired by the negative assertion (and, BTW, a non greedy quantifier, ".*?", would have exactly the same result in this specific case). And my whole point in my various posts was not so much to provide a solution (although I think I actually did), but rather to answer the OP's deeper question and to explain the OP why his or her code did not work, namely that the ".*" within the match subexpression prevented the negative lookahead assertion from matching anything, thereby allowing the whole regex to match despite the negative assertion, which was obviously not the desired result. And all of my examples were aimed at showing this. The two examples in my very first post already showed how the presence of ".+" within the match changed completely the result (made the negative assertion to fail), whereas, without that ".+", the negative assertion succeeded (and the overall regex thus failed). These things are not very easy to explain and quite possibly I was not clear enough (maybe it is also due to English not being my mother tongue -- sorry if my English is too poor), but I think I showed quite relatively clearly several times and already in my very first post and its code examples that the failure of the negative lookahead assertion was due to the catch-all-the-rest-of-the-line ".*" (or, in this case, equivalent ".+") within the match subexpression preceding the negative assertion.
|