Hi Marshall,

I did a copy and paste from my dev environment which is not exactly the same as running from the command line directly.

Sure, that's a possibility. Even something as seemingly simple as perl foo.pl | grep bar or even perl foo.pl | cat on the terminal will cause Perl to turn off line buffered mode on STDOUT and cause the need for $|++ if you want "live" output.

Regards,
-- Hauke D

Yes, that is what is happening. I very seldom run Perl directly from the command line without redirecting output to a file.

I do most of my work on Windows and for reasons that mystify me, writing to the command window terminal is super duper slow. Many of my programs are written as Unix style filters and often they will become I/O limited to the STDOUT terminal speed without STDOUT and/or STDERR re-direction to a file. Other O/S'es that I've worked on just fly 5K lines to the terminal in a blur - but not Windows. Windows must have some sort of max speed throttle when writing to the command window. If anybody knows to increase that speed, I'd like to know!

I use Textpad for Perl dev on Windows. It captures STDERR and STDOUT to a new edit window when I "push the Perl "go" button". I come across the need for $|=1; all the time and I've gotten used to that quirk so much that I don't think about it much.

I think this completely explains my results.

Hi Marshall,

I just wanted to point out the -t operator that tests whether a filehandle is connected to a TTY. I don't know if this is the same mechanism that Perl uses to decide whether to use line-buffered mode or not, and I dimly remember reading somewhere that the -t test isn't always reliable, but anyway, this snippet would probably also confirm the issue.

$ perl -e 'warn "STDOUT ".(-t STDOUT?"IS":"is NOT")." a TTY\n"'
STDOUT IS a TTY
$ perl -e 'warn "STDOUT ".(-t STDOUT?"IS":"is NOT")." a TTY\n"' | cat
STDOUT is NOT a TTY
[download]

Regards,
-- Hauke D