Ack & Negative Lookahead Giving Errors

Ack & negative lookahead giving errors

Try ack-grep 'paypal_responded(?!_at)'

You need single-quote to avoid bash interpret ! as history expand command.

Regex lookahead for 'not followed by' in grep

Negative lookahead, which is what you're after, requires a more powerful tool than the standard grep. You need a PCRE-enabled grep.

If you have GNU grep, the current version supports options -P or --perl-regexp and you can then use the regex you wanted.

If you don't have (a sufficiently recent version of) GNU grep, then consider getting ack.

RewriteRule using Negative Lookahead results in Server Error

When the file is placed on the server, the result is Internal Server Error

You are getting 500 (Internal Server Error) because your rule is running into loop as regex pattern keeps matching rewritten URL also which is /dir/.

You may use this rule to fix this:

RewriteRule ^([^/]+)/(?!.*(contact|about|subscribe|favorite)).+$ $1/?section=other [QSA,L,NC]

Note use of .+ after / to prevent it to match just /dir/.

Updated RegEx Demo

Regex negative lookbehind and lookahead: equivalence and performance

Is it going to have an impact on performances?

In most cases, the more steps a regex needs to find a match, the slower the performance is. Although it also depends what platform you will use the regex in later (say, if you test a regex for use in .NET using regex101.com, it does not mean it will cause a catastrophic backtracking with a lazy dot matching regex failing with a long text).

Are the two regex really functionally equivalent?

No, they aren't. (?<!\.png|\.css)$ finds an end of the line that is not preceded with .png or .css. ^(?!.*[.]png|.*[.]css$).*$ finds lines that do not contain .png or the lines that do not end with .css. To make them "equivalent" (that is, if you want to make sure the lines ending with .png or .css are not matched), use

^(?!.*[.](?:png|css)$).*$
         ^^^^^^^^^^^^

Make sure the $ is checked after both png and css in the negative lookahead.

There will still be the difference between the regexps: the first will just match the end of the line, and the second will match the whole line.

Is there a way to speed up the lookbehind solution?

Note that the lookbehind in Pattern 1 is checked at each location inside the string. The lookahead in Pattern 2 is only checked once, at the very beginning of the string. That is why an anchored lookahead solution will be faster UNDER one condition - if you cannot use a RightToLeft modifier that is only available in few regex flavors (e.g. .NET).

The $(?<!\.(?:png|css)$) lookbehind solution is faster than Pattern 1 because the lookbehind pattern is checked just once, after reaching the end of string/line. Still, this takes a bit more steps because of the implementation of a lookbehind that is costlier than a lookahead.

To really find out which solution is fastest, you need to set up performance tests in your environment.

Regex Negative Lookahead Is Being Ignored

Let's go through what happens when matching your pattern on item 1:

• \[(.*)\] matches [Item 1]
• .* matches (./path/notes.md
• The remaining string is now )
• (?!notes\.md) checks whether the remaining string matches the pattern notes\.md. It does not, so the match continues.
• \) matches the ) and the match succeeds.

If you change it so that the .* before the lookahead is inside the lookahead instead (\[(.*)\](?!.*notes\.md).*\)), it will now work as follows:

• \[(.*)\] matches [Item 1]
• The remaining string is now (./path/notes.md)
• (?!.*notes\.md) checks whether the remaining string matches the pattern .*notes\.md, which it does, so the match fails (well more precisely, the regex engine will try to backtrack before it gives up on the match, but there's no alternative way to match \[(.*)\]', so the match still fails).

So with that change, it will reject all strings where notes.md appears anywhere before the ). If you want it to only reject instances where notes.md appears directly before the ), you can use a loookbehind (without .*) instead or add the \) to the lookahead.

Error using both lookahead and look behind regex

JavaScript regex does not support lookbehind at all.

Sources:

• http://www.regular-expressions.info/lookaround.html#limitbehindand
• http://www.regular-expressions.info/javascript.html
• https://developer.mozilla.org/en-US/docs/JavaScript/Guide/Regular_Expressions

However, you can fake it in some cases.

regex AND operator with negative arguments

Just use a negative lookbehind.
This matches exactly what you asked for: ^.*+(?<![.!]"?)$

---

^ - beginning of line

.*+ - any amount of characters, not giving up for backtracking

(?<! + ) - not preceded by

[.!] - dot or exclamation mark

"? - optional double-quote

$ - end of line

Ignoring a word in regex (negative lookahead)

The MovieClose group can match 3-6 chars A-Z and Deku has 4 chars. If that part should not contain Deku, you could use the negative lookahead predeced by repeating 0+ times a character class [A-Za-z]* as it can not cross the -.

To prevent matching eku-124, you could prepend a word boundary before the MovieClose group or add (?<!\S if there should be a whitespace boundary at the left.

Note that you can omit {1} from the pattern.

\b(?P<MovieCode>(?![A-Za-z]*Deku)[A-Za-z]{3,6}-\d{3,5})(?P<MoviePart>[A-C]\b)?

Regex demo

Redshift / Regular Expression (Negative Lookahead) does not work

Acc. to the Amazon Redshift documentation, the regular expressions you can use with ~ operator comply with the POSIX standard. That means there is no lookaround support and you cannot use (?!...), nor (?<!...) constructs in these patterns.

It seems that you want to match a string if it does not start with a pattern. In this case, you may use the negated regex operator version, !~.

where column_a !~ '^abc'

---

Related Topics