Capturing stdout from test code is inconsistent

[MicahChalmer]

The feature that captures "stdout" for tests doesn't capture all the ways that a test could print to stdout.

#[test]
fn output_capture_tests() {
    println!("This gets captured...");
    let _ = std::io::stdout().write_line("but this does not...");
    let _ = std::task::try(proc() { println!("..and neither does this...") });
    let _ = std::run::process_status("/bin/echo", [~"...nor this..."]);
    fail!();
}

Only the first println! call gets captured--the rest appear intermingled with the test output:

running 1 test
but this does not...
..and neither does this...
...nor this...
test output_capture_tests ... FAILED

failures:

---- output_capture_tests stdout ----
    This gets captured...
    task 'output_capture_tests' failed at 'explicit failure', subproc-test-stdout.rs:7


failures:
    output_capture_tests

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured

It would be nice if all of these got captured.

[alexcrichton]

In my opinion, the only real bug here is that the child task's println isn't captured. Capturing stdout/stderr is not supposed to be comprehensive, it's supposed to clean up the output.

You'll almost always be able to subvert whatever capturing is going on, it's not supposed to be exhaustive.

[MicahChalmer]

Ok, so std::io::stdout() will always hit the process-wide FD 1 (not task-local), whereas the functions in std::io::stdio will write to a task-local "stdout" which could be redirected at spawn time. Perhaps the task-local "stdout" should have a different name? Otherwise this could get rather confusing. I think people will expect the term "stdout" to always refer to the process global version. "Task default output" maybe?

If the task-local one is still going to be named "stdout", then I think the documentation will need to be updated in a lot of places to make it explicit which "stdout" is being used. For instance, the documentation of std::io::stdio::println refers to "the stdout of the current process"--but that's no longer the case, now it's "the stdout of the current task" (and probably an explanation of how that is not the same thing as the stdout of the current process.)

Once that distinction is clear, it's natural to assume that child processes will inherit the process global FD, so I see why that's not a bug. It's easy enough to capture the output and print it to the task's "stdout".

[steveklabnik]

This is still true today with Thread::scoped.

[aturon]

Nominating for 1.0-beta P-backcompat-libs. We need to finalize our capture story.

[pnkfelix]

1.0 beta, P-backcompat-libs, I-needsdecision

[aturon]

triage: (1.0)

[aturon]

triage: P-high (1.0)