the re pragma may be your friend here:

use re qw(debug);
( "hello Gags" =~ /^(?=hello).*[^G][^a].*$/ )&& print ("Matched") || p
+rint ("Unmatched");
[download]

Should give you more information than you need.

/J\

That's a very handy tool indeed!!!
Is there anywhere that I can find any docs on it?
I've to run for my train, thanks again for your help.

Thanks,
Mark.

perldoc re

HTH

Sweetblood

"(?=hello)" matches "hello"
".*"        matches "hello Ga"
"[^G]"      matches "g"
"[^a]"      matches "s"
".*"        matches nothing
[download]

( "hello Gags" =~ /^(?=hello)(?!.*Ga/ )&& print ("Matched") || print (
+"Unmatched")
[download]

use strict;
( "hello Gags" =~ /^(?=hello)(.*)([^G][^a])(.*)$/ ) ?  matches() : pri
+nt ("Unmatched");

sub matches {
  no strict 'refs';
  for (1..10) {
    my $tmp = ${$_} or next;
    print "\$$_ = '$tmp'\n";
  }
  return 1;
}

__OUTPUT__
$1 = 'hello Ga'
$2 = 'gs'
[download]

It's nearly always easier and quicker (in coding time if not execution time) to code that sort of test using separate regexes and boolean operators than it is a single regex.

$_ = "hello Gags"; 
if( /hello/ and not /Ga/ ) { 
    print 'Matched' 
} 
else { 
    print 'Failed' 
};

Failed
[download]

... locates the word 'hello' then if the rest of the string ...

This is your first problem: a lookahead peeks into the string, but doesn't change the position that the rest of the string will attempt to match at. You don't want a lookahead for this, but a straight match - then the rest of the pattern will correctly be tried against the rest of the string:

  /^hello.../
[download]

... if the rest of the string DOES NOT contain the char 'G' followed by the char 'a' ...

A simple negative lookahead:

  /
    (?!   # fail to match if you find (
      .*  #   zero or more characters
      Ga  #   followed by "Ga"
    )     # )
  /x
[download]

So your specification is satisfied simply by:

  /^hello(?!.*Ga)/
[download]

Hope this helps,

Hugo

Personally, I think that the way you wrote that statement is evil and such constructs should be avoided. I really shouldn't have to think too hard about operator evaluation order to figure out how your code works. You could have at least put parentheses around the operands of the &&. As the code presently exists, I'd have to run it through a debugger to convince myself that it works the way you claim it works.

Maybe this is an extreme opinion, but I think I'd prefer that compilers/interpreters forced you to parenthesize for stuff like that, and threw ambiguity errors when you didn't.

yer.. the OP should have used something like:
 print /foo/ ? 'bar' : 'baz'
IMO