Problem with negative lookahead at end of string

[olivierp]

Hi Monks ! I'm having trouble building a regex that would match as follows:
string starts with chars, contains this, but does not contain that and does not end with whatever A couple of samples:

• chars at the beginning, this is right and whatever is not at the end
• chars at the beginning, this is ok and the end is whatever
• chars at the beginning, this is ok and that is included
• chars at the beginning, that here this is not ok

This regex will match 1 and 2, and correctly skip 3 and 4:

^chars(?!.*that).*this(?!.*that).*

If I include the whatever part, as here

^chars(?!.*that).*this(?!.*that).*(?!.*whatever)$

, sample 2 still matches, whereas this:

^chars(?!.*that).*this(?!.*that).*[^w][^h][^a][^t][^e][^v][^e][^r]$

excludes sample 2 but is horrible...

Am I missing something with the negative lookahead, or is it not possible to do such a thing ?
Edited by demerphq: Changed </br> to <br />

[merlyn]

For simplicity sake, you can list a compound "and-ed" condition as a series of null assertions:

/
  ^ # anchor so as not to try this at every spot
  (?= chars ) # stars with chars
  (?= .*? this ) # contains this
  (?! .*? that ) # does not contain that
  (?! .* whatever $ ) # does not end in whatever
/xs

update: edited to include additional whitespace for readability

[melora]

Nice. "I'd walk a mile for a (Programming Perl) Camel." Had to reach for it to get through that ?!.*? regex! I'm just an old C programmer, learning more than one way to do it...

[tye]

/^chars(?!.*that).*this.*(?<!whatever)$/

If "whatever" is actually a pattern that can match more than a single length of string, then instead use:

/^chars(?!.*that).*this(?!.*whatever$)/

And note that the (?!.*that) part doesn't need to be repeated.

[delirium]

Despite a processing slowdown, I prefer the readability of splitting criteria like this up into multiple expressions:

/^chars/ && /this/ && !/that/ && !/whatever$/

[runrig]

Despite a processing slowdown...

It depends on the patterns and the string, but it's often faster (and in this case it is faster) to split up the matches into multiple regexes.