Getting less output using prove's --merge option

[nysus]

I'm trying to figure out why prove's --merge option gives me different output after running this test file:

use strict;
use warnings;
use Test::More;

ok 1;
ok 0;

done_testing();

With --merge:

> $ prove  --merge t/test.t                                           
+                                         
t/test.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests

Test Summary Report
-------------------
t/test.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=1, Tests=2,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.01 cusr 
+ 0.00 csys =  0.02 CPU)
Result: FAIL

And without:

> $ prove  t/test.t                                                   
+                                          
t/test.t .. 1/?
#   Failed test at t/test.t line 6.
# Looks like you failed 1 test of 2.
t/test.t .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/2 subtests

Test Summary Report
-------------------
t/test.t (Wstat: 256 (exited 1) Tests: 2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=1, Tests=2,  0 wallclock secs ( 0.01 usr  0.00 sys +  0.01 cusr 
+ 0.00 csys =  0.02 CPU)
Result: FAIL

I get a more detailed report without merge. I'm not sure why. I thought merge was supposed to merge STDERR into STDOUT so I didn't think there should be a difference. Merge docs say:

--merge

If you need to make sure your diagnostics are displayed in the correct order relative to test results you can use the --merge option to merge the test scripts' STDERR into their STDOUT.

This guarantees that STDOUT (where the test results appear) and STDERR (where the diagnostics appear) will stay in sync. The harness will display any diagnostics your tests emit on STDERR.

Caveat: this is a bit of a kludge. In particular note that if anything that appears on STDERR looks like a test result the test harness will get confused. Use this option only if you understand the consequences and can live with the risk.

[choroba]

I'm not sure what the problem is, but for non-MSWin, the culprit is this block:

else {
    $err = $merge ? '' : IO::Handle->new;
    eval { $pid = open3( '<&STDIN', $out, $err, @command ); };
    die "Could not execute (@command): $@" if $@;
    $sel = $merge ? undef : IO::Select->new( $out, $err );
}

What's going on there? Seems like $err is set to an empty string, which should create a new filehandle when calling open3. Then $sel is then set to undef, but I have no idea what that means.

[nysus]

Bug report filed

[nysus]

Thanks. Yup, I'm on a mac. So this is a bug with Test::Harness, right? Should I file a report? I had already looked at Test::Harness bug reports. Also found this email on the mailing list. Not sure if it's related.

[nysus]

I just discovered that if I throw the -v option in there, the output is identical with or without --merge.