New Perl5 regexp behaviour - bug? 
Author Message
 New Perl5 regexp behaviour - bug?

The Perl code below show a difference in the handling of $1 after a regexp.
In Perl 4, when a regexp using grouping () failed $1 ended up undefined.  In
Perl 5 $1 remains unchanged, retaining it's previous value.  Is this a bug or
have I simply missed this in the docs?

#!/usr/local/bin/perl5 -w

$_ = 'bug';
/(bug)/;
print "\$1=$1.\n";
$_ = "left nomatch right";
/(middle)/;
($left, $middle, $right)=($`, $1, $');
print "\$left=$left, \$middle=$middle, \$right=$right.\n";

If you run this $middle has a value of 'bug' where it used to be undefined.

Steve



Sat, 03 May 1997 00:14:07 GMT  
 New Perl5 regexp behaviour - bug?
: The Perl code below show a difference in the handling of $1 after a regexp.
: In Perl 4, when a regexp using grouping () failed $1 ended up undefined.  In
: Perl 5 $1 remains unchanged, retaining it's previous value.  Is this a bug or
: have I simply missed this in the docs?
:
: #!/usr/local/bin/perl5 -w
:
: $_ = 'bug';
: /(bug)/;
: print "\$1=$1.\n";
: $_ = "left nomatch right";
: /(middle)/;
: ($left, $middle, $right)=($`, $1, $');
: print "\$left=$left, \$middle=$middle, \$right=$right.\n";
:
: If you run this $middle has a value of 'bug' where it used to be undefined.

What version of Perl 4 are you running?  I find it works the same as
Perl 5 for all the versions of Perl 4 I have{*filter*} around.

In any event, an unsuccessful pattern match is not supposed to have any
effect on the values of backreference variables.  The book is a little
clearer on this than the manpage.  "All of these variables are associated
with the last *successful* pattern match."

Larry



Tue, 06 May 1997 04:57:56 GMT  
 New Perl5 regexp behaviour - bug?

Quote:


>: The Perl code below show a difference in the handling of $1 after a regexp.

.....

Quote:

>What version of Perl 4 are you running?  I find it works the same as
>Perl 5 for all the versions of Perl 4 I have{*filter*} around.

>In any event, an unsuccessful pattern match is not supposed to have any
>effect on the values of backreference variables.  The book is a little
>clearer on this than the manpage.  "All of these variables are associated
>with the last *successful* pattern match."

OK, thanks.

Here's another sample for you to try.  The bug is data dependant.
Here's the program and the Perl 4 and Perl 5 output.  The Perl 5
output changes depending on the contents of the initial string $_.
Also note that Perl 4 detects that $1 is initially undefined but Perl 5
fails to make that diagnosis.

Perl 4.036 & Perl 5.000, AIX 3.2.5.

$_='abcdefghij';
print "\$1 before=$1.\n";
($_) = ($_ =~ /^(.*)$/);
print "_=$_.\n";
/(nomatch)/;
print "\$1 after=$1.\n";

Perl 4 output:

/perl4 -w sample_pl
Use of uninitialized variable at sample_pl line 2.
$1 before=.
_=abcdefghij.
$1 after=.

Perl 5 output:

/perl5 -w sample_pl
$1 before=.
_=abcdefghij.
$1 after=
          O     .

Here's another Perl 5 output after making this change:

$_='Frogs lacking lipophores are blue.';

/perl5 -w sample_pl
$1 before=.
_=Frogs lacking lipophores are blue..
$1 after=$1 after=cking lipophores are blu.

Take care,
Steve
--

Lehigh University Computing Center, USA



Wed, 07 May 1997 03:53:27 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Bug in perl5.00404: strange behaviour of eval qx{}

2. disturbing behaviour in perl5.001m (bug?)

3. Perl5 extended regexp bug and/or feature

4. Bug in perl5? (comments affect regexp)

5. Perl5.001: bug in regexp matching

6. Perl5 regexp bug?

7. regexp match bug in perl5

8. regexp: strange behaviour (it works but it doesn't)

9. Confused by regexp behaviour

10. Baffled by regexp behaviour

11. Another Odd Regexp Question - Buggy Behaviour?

12. bizarre regexp behaviour with split

 

 
Powered by phpBB® Forum Software