Why '' Is Matched First Time, Not Second Time

[http://links.i6networks.com]

##################Perl File
my @line=(); my $foundcat=0;
my $keyword1=''; my $keywordcat='';
open ($INPUT, 'ostkall.txt') || die "can't open $file: $!";
while (<$INPUT>) {
chomp;
if (!($_=~ m/.+\|.+\|.+/)) {
if
($_=~ m/$keywordcat/i)
{
$foundcat=1;
print "FOUND $_\n";

} else {$foundcat=0;}
} #end of if (!($_=~ m/.+\|.+\|.+/)

}
close($INPUT) ;

#####################The output is
FOUND Computers & Printers|Monitors

But it should be
FOUND Computers & Printers|Monitors
FOUND Computers & Printers|Priners


#################the data in ostkall.txt is
Computers & Printers|Monitors
| | | | |
Computers & Printers|Printers
| | | | |

############# Question
Empty String '' is matched the first time but not the second time. Why?

 

[Gunnar Hjalmarsson]

Empty String '' is matched the first time but not the second time.
Why?

When you noticed that the m// operator does not behave as you had
expected, you did apparently not check the description of the m//
operator in "perldoc perlop". Why?

 

[Eric Bohlman]

##################Perl File
my @line=(); my $foundcat=0;
my $keyword1=''; my $keywordcat='';
open ($INPUT, 'ostkall.txt') || die "can't open $file: $!";
while (<$INPUT>) {
chomp;
if (!($_=~ m/.+\|.+\|.+/)) {
if
($_=~ m/$keywordcat/i)
{
$foundcat=1;
print "FOUND $_\n";

} else {$foundcat=0;}
} #end of if (!($_=~ m/.+\|.+\|.+/)

}
close($INPUT) ;

#####################The output is
FOUND Computers & Printers|Monitors

But it should be
FOUND Computers & Printers|Monitors
FOUND Computers & Printers|Priners


#################the data in ostkall.txt is
Computers & Printers|Monitors
| | | | |
Computers & Printers|Printers
| | | | |

############# Question
Empty String '' is matched the first time but not the second time. Why?

I must admit I played around with your code for about 15 minutes, got
rather puzzled, and then got this nagging feeling "there must be something
special about null-string matches." So I did what every good Perl
programmer does when they get such a feeling and read the section on the
match operator in perlop. Sure enough, there it was:

"If the PATTERN evaluates to the empty string, the last successfully
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)."

When you read the very first line, no regexp has yet successfully matched,
so /$keywordcat/ matches the empty string. When you read the next line,
/.+\|.+\|.+/ successfully matches, so when you go on to read the third
line, /$keywordcat/ is now being treated as /.+\|.+\|.+/, which of course
doesn't match there.

BTW, another thing good Perl programmers do is put 'use warnings;' and 'use
strict' at the top of their programs. If you did that, you'd see that your
error message for the open was using a variable that gallopped in from
nowhere.

 

[http://links.i6networks.com]

I must admit I played around with your code for about 15 minutes, got
rather puzzled, and then got this nagging feeling "there must be something
special about null-string matches." So I did what every good Perl
programmer does when they get such a feeling and read the section on the
match operator in perlop. Sure enough, there it was:

"If the PATTERN evaluates to the empty string, the last successfully
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)."

When you read the very first line, no regexp has yet successfully matched,
so /$keywordcat/ matches the empty string. When you read the next line,
/.+\|.+\|.+/ successfully matches, so when you go on to read the third
line, /$keywordcat/ is now being treated as /.+\|.+\|.+/, which of course
doesn't match there.

I still don't understand. Why perl will do that weired, none normal thing.
Thanks alot. I was right not to waste more time on my own and came here to
ask. Saved my time for a game and a meal.

 

[Sam Holden]

I must admit I played around with your code for about 15 minutes, got
rather puzzled, and then got this nagging feeling "there must be something
special about null-string matches." So I did what every good Perl
programmer does when they get such a feeling and read the section on the
match operator in perlop. Sure enough, there it was:

[snip perl doc quote]

I still don't understand. Why perl will do that weired, none normal thing.
Thanks alot. I was right not to waste more time on my own and came here to
ask. Saved my time for a game and a meal.

So wasting everyone elses time, so that someone can read the standard
documentation to you is worth saving yourself the time of reading the
relevant docs?

*plonk*

 

[Tad McClellan]

"Eric Bohlman" <[email protected]> дÈëÓʼþ


I was right not to waste more time on my own

No you weren't.

You were wrong to not read the documentation for the operator
that you were using.

We are not here to read the docs to you!

Saved my time

At the expense of other people.

Not being a very good "community member" there you know.

So long.

 

[greymaus]

When you noticed that the m// operator does not behave as you had
expected, you did apparently not check the description of the m//
operator in "perldoc perlop". Why?

AFAIK, it does the same in `vi'?

 

[Eric Amick]

I still don't understand. Why perl will do that weired, none normal thing.

Because of historical precedent, I suspect. Perl's s/// operator does
the same thing with an empty pattern, and the behavior is the same in
various Unix editors that predate Perl. And there's a practical reason
for giving it a special meaning--since *every* line in a file would
match an empty pattern if that pattern meant an empty string, why not
give it some useful meaning?

Thanks alot. I was right not to waste more time on my own and came here to
ask. Saved my time for a game and a meal.

Interesting logic. The answer was right in the docs, but apparently we
are here to read the docs for you. Clearly our time is less valuable
than yours. I don't think so.

 

[http://links.i6networks.com]

thing.

Because of historical precedent, I suspect. Perl's s/// operator does
the same thing with an empty pattern, and the behavior is the same in
various Unix editors that predate Perl. And there's a practical reason
for giving it a special meaning--since *every* line in a file would
match an empty pattern if that pattern meant an empty string, why not
give it some useful meaning?


Interesting logic. The answer was right in the docs, but apparently we
are here to read the docs for you. Clearly our time is less valuable
than yours. I don't think so.

It only take others 2 minutes to point out and will costs me 2 days before
giving up. I would say costing others two minutes worth saving my two day
without any result. You guys did not read my saying correctly. I was saying
it is so much quicker using a good helper than reinvent the wheel.

 

[Gunnar Hjalmarsson]

It only take others 2 minutes to point out and will costs me 2 days
before giving up.

2 days? I don't believe you. Not even you are *that* stupid.

I would say costing others two minutes worth saving my two day
without any result. You guys did not read my saying correctly.

I think they did read your message correctly. You are just another one
of those lazy, egocentric persons who post here all too often.

I was saying it is so much quicker using a good helper than
reinvent the wheel.

Would reading the docs be the same as reinventing the wheel? Idiot!

 

[Sherm Pendley]

*PLOINK*

You might want to take that killfile in for servicing - it sounds a bit off.

sherm--