my $sss = "M9";
if ($sss =~ m/(\d+)/){
    print "Value Matched on: $1\n";    # prints Value Matched on: 9
}

$sss = "Mm";
if ($sss =~ m/(\d+)/){
    print "Value Matched on: $1\n";    # if statement is not entered
}

print "\$1 holds $1!\n";
[download]

The generally accepted wisdom is to use conditionals exclusively if you're capturing things. You could also add an else clause, undefining $1.

if ($sss =~ /(\d+)/) {
  # use $1 as you wish
}
else {
  # don't!
}
[download]

--ZZamboni

No, $1 will not be undef if the match fails. The only time they are undefined is when a match has not yet been done, or a match does not contain a captured pattern for that variable:

#!/usr/bin/perl -w

if ("abc" =~ /(\w+)/, 1) { print "abc => $1\n" }
{ 
  print "local: $1\n";
  if ("ghi" =~ /\w+/, 1) { print "ghi => $1\n" }
  if ("def" =~ /(\w+)/, 1) { print "def => $1\n" }
  if ("[=]" =~ /(\w+)/, 1) { print "[=] => $1\n" }
}
print "general: $1\n";

__END__
abc => abc
local: abc
Use of uninitialized value at regexes line 6.
ghi => 
def => def
[=] => def
general: abc
[download]

However, a failed match returns false, so if you removed the , 1's from each of those, you wouldn't see the line for "=".

japhy -- Perl and Regex Hacker

I agree completely with you, and that's what I meant, that if the regex does not match, $1 is not modified in any way (neither set or unset). But your example made it way clearer than any explanation :-)

--ZZamboni

use strict;

my $i = "mmmm9";
my $a = match_rtn( $i );
print $a, "\n";

$i = "mmm";
$a = match_rtn( $i );
print $a, "\n";

sub match_rtn {
    my $str = shift;

    $str =~ m/(\d+)/;
    return $1;   
}
[download]

I looked up exactly what 'strict' is supposed to do, and the Camel book says its supposed to disallow "unsafe" code. My question to anyone else is what is considered "unsafe"?

Amel - f.k.a. - kel

Your method of enclosing the match operation only *appears* to work (in terms of leaving $1 unmodified after the sub call, and returning undef on failure), but not at all for the reasons you provide. The use of 'strict' has nothing to do with producing the undef value, and 'strict' has nothing to do with how variables are scoped. Had any successful match been applied in the outer scope prior to your sub calls, then $1 (which is global) would have been set there and its value would be the return value on any of your sub calls that failed to match. Check this minor variation on your example:

use strict;
"blah" =~ /(a)/;       # now we've set $1 at the global scope

my $i = "mmmm9";
my $a = match_rtn( $i );
print $a, "\n";

$i = "mmm";
$a = match_rtn( $i );
print $a, "\n";        # ook! this isn't undefined!

sub match_rtn {
    my $str = shift;
    $str =~ m/(\d+)/;
    return $1;   
}
[download]

Match variables ($1, $2, etc.) are global variables. When match variables are set (due to a successful match operation), they are always localized to the enclosing block. So, they retain their value until another successful pattern match, or the end of the current block. Witness:

{
    $_ = 'blah';
    /(a)/;
    print "$1\n"; # prints: a
}

print "$1\n"; # unitialized warning
[download]

Now try this longer example and you'll see that the match variables are implicitly localized (ie, in the sense of local()):

$_ = 'blah';
/(\w)/;
print "$1\n"; # prints: b
/(\d)/;
print "$1\n"; # still prints: b

{
    /(a)/;
    print "$1\n"; # prints: a
}

print "$1\n"; # prints: b
[download]

The proper way to protect yourself from using unintended old values in $1 and friends is to program defensively and check if a pattern match succeeded before trying to use captured subexpressions (as previous messages in this thread have shown).

I looked up exactly what 'strict' is supposed to do, and the Camel book says its supposed to disallow "unsafe" code. My question to anyone else is what is considered "unsafe"?

Please see the documentation for strict and tye's review of strict.pm for starters.

The proper way to protect yourself from using unintended old values in $1 and friends is to program defensively and check if a pattern match succeeded before trying to use captured subexpressions (as previous messages in this thread have shown).

Well, that's a way. Another way is to stylistically outlaw all uses of $1 et seq, except in the right side of a substitution. Any other "capturing" should be done as list-context assignment:

my ($first, $second) = $source =~ /blah(this)blah(that)blah/;
[download]

Then it's very clear what the scope and origination of $first and $second are.

-- Randal L. Schwartz, Perl hacker

I looked up exactly what 'strict' is supposed to do, and the Camel book says its supposed to disallow "unsafe" code. My question to anyone else is what is considered "unsafe"?

I don't know whether you're looking at Camel II or III, but they both provide full documentation on strict. The Second edition documents the strict pragma beginning on page 500, and the Third edition beginning on page 858.

Of course, the Camel book is not the only source of documentation. Each core module and pragma also comes with built-in documentation. You can read the standard documentation for strict with perldoc strict (or the equivalent on Windows [the HTML-ized docs] or Mac [Shuck]).

The docs from 5.005_02 are even available on this site, including the docs for strict.

To answer your question, three things are considered 'unsafe'. Each one is controlled by a separate part of strict. strict 'refs' prevents the use of symbolic references. strict 'vars' prevents the use of variables which are not pre-declared or fully qualified. strict 'subs' prevents the use of barewords.

That much I got(didn't mean to sound like a d**khead). What I don't get is why that is unsafe. Is it because bareword could be confused with a built in function or something like that? Why are undeclared variables unsafe? Same kind of thing?

Excuse my ignorance. I am starting to really get interested in the theories of programming and things like that and I would really like to get a handle on this stuff. I taught myself Perl about a year ago and I've had no one to ask these questions to. They are all sort of flooding out now.

Thanks for your help.

Amel - f.k.a. - kel