On 9/4/06, Ovid <[EMAIL PROTECTED]> wrote:
Once again we have an example of how using different output streams for regular and diagnostic information causes serious problems. This is the worst I've seen. In one method I'm testing I embedded the following:use Data::Dumper; ::diag(Data::Dumper->Dump( [$stripped, [EMAIL PROTECTED], [qw<$stripped *records> ] )); And here's the output in the test: ok 14 - ... and splitting the sql into individual statements should succeed # $stripped = 'alter table test_colors add column foo varchar(200)'; ok 15 - ... and splitting the sql should succeed # @records = ( ok 16 - ... but the original SQL should remain unchanged # 'alter table test_colors add column foo varchar(200)' # ); not ok 17 - We should be able to "split" a single statement Ouch. This is what I 'normally' see when I run this: ok 14 - ... and splitting the sql into individual statements should succeed ok 15 - ... and splitting the sql should succeed ok 16 - ... but the original SQL should remain unchanged # $stripped = 'alter table test_colors add column foo varchar(200)'; # @records = ( # 'alter table test_colors add column foo varchar(200)' # );
This looks like buffering issues to me. I see stuff like this all the time when i run code through an editor. Perl tests to see if stdout (and maybe stderr) are terminals and then automatically turns on auto-flush when they are. But when i launch the script via my editor apparently perl thinks its not dealing with a terminal and doesnt buffer the filehandles, resulting in output much like you have above. So i wonder if you manually turn on autoflushing of all the output handles if that helps. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
