I would use ^FOO(?!BA[RZ]\b).*$, ie put the \b inside the look-ahead. Otherwise, only 'FOO' is matched.

$ perl -le '/^FOO(?!BA[RZ]\b).*$/ and print for qw/FOOBAR FOOBARS FOOB
+AZ FOOBAZS FOOQUX FOO/'
FOOBARS
FOOBAZS
FOOQUX
FOO
[download]

Update: added example

The word boundary does not help, because for instance 'FOOBAR X' and 'FOOBARX' are both strings which should be accepted (because both BAR X and BARX are considered different from <BAR>), while 'FOOBAR' should be rejected.

Actually I meanwhile believe to having found a solution to my problem while having lunch (it is surprising how a glass of Italian Chardonnay can do good to the brain cells):

$name =~ /^FOO(?!(BAR|BAZ)$)/
[download]

so unless someone can find a flaw with this (the examples where I tried it, worked so far), I think I will stick with it. It is not a beautiful solution, though, because if I would like one day to pick up what is to the right of FOO, I can't do it. So I'm still interested in hearing alternative proposals.

Maybe just to make it clear, here are concrete examples: The following strings should be accepted:

FOOABC
FOO_BAR
FOOBA
FOOBAZZZZ
FOOBAR BAZ
[download]

while the following should be rejected:

FOOBAR
FOOBAZ
BARBAZ
[download]

-- 
Ronald Fischer <ynnor@mm.st>

"it is surprising how a glass of Italian Chardonnay can do good to the brain cells"

But it is far from surprising that providing a clear specification of what you seek will enhance the liklihood that the Monks will provide useful advice.

I mention this because your original post. The first bit of code, [/^(BAR|BAZ)$/, requires that /BA[RZ]/ NOT be the last element of your string, while the second, the negative lookahead, (?!(BAR|BAZ)).*$/, allows anything NOT /BA[RZ]/ followed by (your dot_deathstar, .* any number of any characters INCLUDING /BA[RZ]/.

Judging by other replies, I wasn't the only one confounded thereby. yet very shortly after your clarifying example (in this node's parent) you got a reasonably general answer from Anonymonk (and re that answer, I'm not sure I buy the advice to "avoid as the plague the use of capturing groups in the decomposed regexes..." but the thought process outlined in that node deserves a ++ ((and got same from me)).