in reply to Break perl foreach loop

I did do a print $x if "Patient" is matched

and

When I put this print in the match condition I want to break the loop, the print comes along at the right place, it's just that the loop continues. if ( $x =~ m/^Patient/ ) { print "matched here "; #goto WID; last WID; }
Are you sure you are actually entering this section, i.e. did you do a distinctive print STDERR from that section (not just a match on patient or vague print "matched here")? As in: 
  ...
  if ($x =~ m/^Patient/) {
    print STDERR "Patient found\n";  #added for verification
    last WID;
  }
  ...

[download]

If you have a match on the ENCODE stuff at the top of the loop, your $x will be set to "Patient" (with quotes) and will match m/^"Patient/ and /Patient/ but not m/^Patient/.

Failing that, I would try to comment out everything except the stuff at the top that sets $x and the if ... last WID stuff and see if you still have the wierd behavior. If you do, start simplifying the code that sets $x until you don't. Then start adding stuff back until you do. The key thing is to isolate the code that triggers this odd behavior.

Best, beth

Update: added quotes of previous debugging efforts, plus some extra suggestions.

Replies are listed 'Best First'.
Re^2: Break perl foreach loop
by pvecchio (Initiate) on Mar 03, 2009 at 19:33 UTC
    The STDERR did not provide any output. Only see something if I 'print' to document. See example output above where it matches after total. It does print based on the match but if I put Last WID before print, it does not print. Only prints if followed by Last WID.

    My sense is that since I don't completely understand the top of the code (I did not write it), from what I see it's putting everything into $x and then performing the matching and print operations after. So ending the foreach comes too late. I think I'd have to delete everything at the end of the array after I first match total.

    Maybe?
[reply]
      Sorry, I was adding thoughts to my post while you were responding. Yes, I think the strategy is to start by commenting out stuff until you no longer get the symptoms and then adding it back.

      I think your hunch about something not quite matching up may be right. I don't think it is the problem here but I remember once driving myself crazy over a bug that was caused by a single missing ; - for some reason the code compiled without syntax errors but line 2 was executing before line 1 and I couldn't figure out why... until I realized that Perl thought line 2 was a parameter to line 1 and so was evaluating it first. Sometimes Perl makes sense of things we rather it wouldn't.

      Best, beth

[reply]
[d/l]
      You could try putting a $|=1; statement at top of program. This turns force flushing on. Each print will get flushed to output as it happens. Maybe the loop really is finishing, but some stuff is stuck in print buffer that you don't see until later?

      I can't see anything wrong with syntax. Of course you don't need the WID label (just like not need for the next's), but you probably already know that.

      Update:I like Beth's suggestion more. Something is strange here that Perl is doing its best with, but not what was intended.

[reply]
        You could try putting a $|=1; statement at top of program. This turns force flushing on. Each print will get flushed to output as it happens.

        That won't affect STDERR at all, for two reasons. First, unless STDERR is the currently-selected filehandle, disabling buffering won't affect STDERR at all. Second, STDERR is likely already unbuffered if it's attached to a tty.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom