sub chg {
        $_ [0] =~ $_ [1] && $1 ? "yes\n" : "no\n";
    }
[download]

Abigail

 sub chg {
       $_ [0] =~ $_ [1] && $1 ? "yes\n" : "no\n";
 }
[download]

Isn't the && $1 redundant here? or am I missing something out?

---

He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

Chady | http://chady.net/

The OP's code was actually returning "yes" if $1 contained a true value. So, the following would've returned "no":

chg("w0rd", qr/(\d)/); # that's a zero, not capital O

bbfu
Black flowers blossom
Fearless on my breath

Well, for one, you should only trust $1 if your regex suceeds. Remember, the $1..$x variables are set after each successful regex with capturing parantheses. However, they are not cleared when a regex doesn't match. You could put the return statements in an if-block. Even better, check out this code. No $1 to worry about.

print BLAH::chg("word", qr/(\d)/);   # print "nope"
"2" =~ /(2)/;
print BLAH::chg("word", qr/(\d)/);   # print "nope"
print BLAH::chg("3", qr/(\d)/);   # print "yes"
                                                                      
+          
package BLAH;
sub chg {
   return $_[0] =~ $_[1] ? "yes\n" : "nope\n";
}

# Alternatively, you can do:
#
# if($_[0] =~ $_[1])
# {
#   return "yes\n";
# }
# return "nope\n";
__OUTPUT__
nope
nope
yes
[download]

HTH

The regular expression captured submatches ($1, $2, ...) are now more consistently unset if the match fails, instead of leaving false data lying around in them.

Not to imply that its actually done consistently though. Just more consistently.

Thanks for the replies.

Are there modules or debugging techniques that can help track down such a logical $1 error? Consider the code below.

print chg("ctag\n", qr/t(g)/);   # print "ctag"
"g" =~ /(c)/;
print chg("ctag\n", qr/t(g)/);   # print "ctag"

print chg("ctag\n", qr/t(g)/);   # print "ctag"
"g" =~ /(g)/;
print chg("ctag\n", qr/t(g)/);   # print "ctga"

sub chg {
    my ($str, $pat) = @_;
    $str =~ /$pat/;
    eval "\$str =~ tr/a$1/$1a/" if $1;
    return $str;
}
[download]

The code will work most of the time except when something like "g" =~ /(g)/ occurs. If I'm using someone else's code or even my own (I can't force someone or myself to write bug-free code), since the logical error occurs only once a while and even if it happens it's not necessarily noticeable, when such an error does occur, $1 is probably not the first thing coming to my mind when trying to debug it, especially when there're no warning messages pointing me to it.

__________________
Are these similar issues whenever using such global variables as $_?

Update: Maybe I should rephrase my question as not just how to avoid this $1 mistake in the first place but how to pinpoint one afterwards should an error already be happening.

Not to sound facetious, but several other posters and I basically answered this question(which is almost identical to your original post) by saying: "Don't do that!" I know it's Perl and TIMTOWTDI, but sometimes the way you are doing it is wrong. Yet again the correct way to write the sub above is:

sub chg {
   my ($str, $pat) = @_;
   eval "\$str =~ tr/a$1/$1a/" if $str =~ /$pat/;
   return $str;
}
[download]

As far as debugging other people's code which is coded like this. I suppose firing up the perl debugger and stepping through the program may shed some light, although something as obscure as your example which only fails with some singularly weird input may be very difficult to figure out. However, if you just shuffle around your house hitting yourself in the head with your Camel book and repeating the mantra, "Never check $1 blindly, make certain my regex succeeded." You will, after much meditation and contemplation, literally "beat" it into your head so whenever you see $1 in someone's code, you will instantly make sure it is properly initialized before it is used.

HTH