Should an empty regex match everything

[Mintcake]

The script at the end of this post produces the folllowing output...
Matching on 'plugh'
Contains the word plugh
Does not contain the word plugh
Matching on 'xyzzy'
Contains the word xyzzy
Matching on ''
1

I don't understand why 3rd call to gettd() does not produce any
matches.

#!/usr/bin/env perl

use strict;
use warnings;

my $tr = <<EOTR;
<tr>
<td>Contains the word plugh</td>
<td>Does not contain the word plugh</td>
<td>Contains the word xyzzy</td>
</tr>
EOTR

sub gettd {
my $regex = shift;
print "Matching on '$regex'\n";
for (grep /$regex/, $tr =~ /<td>(.*?)<\/td>/g) {
print " $_\n";
}
}

gettd('plugh');
gettd('xyzzy');
gettd('');

my $regex = '';
my $str = 'Any old string';
print $str =~ /$regex/, "\n";

 

[Peter Makholm]

I don't understand why 3rd call to gettd() does not produce any
matches.

Because a pattern consisting of the empty string has a special
meaning, documented in perlop:

If the PATTERN evaluates to the empty string, the last success-
fully matched regular expression is used instead. In this case,
only the "g" and "c" flags on the empty pattern is honoured -
the other flags are taken from the original pattern. If no
match has previously succeeded, this will (silently) act
instead as a genuine empty pattern (which will always match).

//Makholm

 

[Randal L. Schwartz]

Mintcake> #!/usr/bin/env perl

Beware this usage... if another user (such as the webserver) has a different
PATH, they'll get a different Perl for this. Not good in the general case.

 

[Mintcake]

Because a pattern consisting of the empty string has a special
meaning, documented in perlop:

If the PATTERN evaluates to the empty string, the last success-
fully matched regular expression is used instead. In this case,
only the "g" and "c" flags on the empty pattern is honoured -
the other flags are taken from the original pattern. If no
match has previously succeeded, this will (silently) act
instead as a genuine empty pattern (which will always match).

//Makholm

Thanks for that. I'm very glad to have it explained. However, I
can't think of a scenario in which you would make use of this
feature. Though of course, I'm sure there are plenty.

 

[Mintcake]

Mintcake> #!/usr/bin/env perl

Beware this usage... if another user (such as the webserver) has a different
PATH, they'll get a different Perl for this. Not good in the general case.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[email protected]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Good point. I'd seen this usage in another post and thought I'd try
it out. I'd actually abandoned the idea since something like...

#!/usr/bin/env perl -l

.... doesn't work.

I don't know how this idiom escaped into my example code without my
permission. I'll be more careful next time.

 

[Michele Dondi]

Thanks for that. I'm very glad to have it explained. However, I
can't think of a scenario in which you would make use of this
feature. Though of course, I'm sure there are plenty.

Actually I've never either used it nor felt a compelling need for it.
To be fair I'm happy that in Perl 6 the "empty" match is being phased
out.


Michele

 

[Michele Dondi]

Don't quote .sig's.

Good point. I'd seen this usage in another post and thought I'd try
it out. I'd actually abandoned the idea since something like...

#!/usr/bin/env perl -l

... doesn't work.

I don't know how this idiom escaped into my example code without my
permission. I'll be more careful next time.

It's controversial: /usr/bin/env was aimed at solving problems with
variable locations of the actual perl interpreter. Eventually it turns
out that it suffers from the same problem it should solve, but anyway
there are people in both camps: those who deprecate it and those who
support it. Often, both with good arguments. FWIW I agree with Randal
and never use env myself.


Michele