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

> I dimly remember reading somewhere that the -t test isn't always reliable

Probably in Perl::Critic::Policy::InputOutput::ProhibitInteractiveTest ? It doesn't say why, but it offers an alternative.

($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
[download]