Re^3: Break perl foreach loop

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.

Comment on Re^3: Break perl foreach loop

Replies are listed 'Best First'.
Re^4: Break perl foreach loop by chromatic (Archbishop) on Mar 03, 2009 at 20:09 UTC
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]
Re^5: Break perl foreach loop by Marshall (Canon) on Mar 04, 2009 at 17:08 UTC
Completely correct! STDOUT is by default buffered. There are a lot of ways that this can "fool you". For example I have one .pl program that runs for many hours, but is not very verbose. $>long_prog.pl >somefile. You watch the size of somefile and it's not getting bigger! But yes, it does get "bigger" it just takes awhile for that to show up in the file size results. It can be that the buffer is like 4KB - Mileage varies. If you have a debug or error statement that prints to STDERR, that can fool you when watching the terminal...the time sequence may be off ...a "normal print" to STDOUT may show up on the screen after a print to STDERR even if the "normal print" happened first. I think we are in agreement here. I don't see any issue.	[reply]