Tracking issue for std::io::set_panic and set_print

[SimonSapin]

std::io contains these two public unstable functions:

/// Resets the thread-local stderr handle to the specified writer
///
/// This will replace the current thread's stderr handle, returning the old
/// handle. All future calls to `panic!` and friends will emit their output to
/// this specified handle.
///
/// Note that this does not need to be called for all new threads; the default
/// output handle is to the process's stderr stream.
pub fn set_panic(sink: Box<Write + Send>) -> Option<Box<Write + Send>> { … }

/// Resets the thread-local stdout handle to the specified writer
///
/// This will replace the current thread's stdout handle, returning the old
/// handle. All future calls to `print!` and friends will emit their output to
/// this specified handle.
///
/// Note that this does not need to be called for all new threads; the default
/// output handle is to the process's stdout stream.
pub fn set_print(sink: Box<Write + Send>) -> Option<Box<Write + Send>> { … }

They both have #[doc(hidden)]. Anyone knows why?

The also both have:

#[unstable(feature = "set_stdio",
           reason = "this function may disappear completely or be replaced \
                     with a more general mechanism",
           issue = "0")]

Their functionality is evidently useful, since the test crate uses them to capture the output of tests on only show it when they fail. External test harnesses would likely want to have similar functionality.

This issue is about eventually stabilizing either these functions or a more general mechanism.

For set_panic, that mechanism might be panic handlers (#30449) though it would be nice to be able to not duplicate most of the work done in the default handler just to change the output stream. This still leaves set_print.

[alexcrichton]

This is legacy behavior on behalf of libtest. The set_panic function should be subsumed by panic::set_handler, and set_print is just to have a nice testing experience.

I don't think we should stabilize either of these (as evident by issue = "0"), and this just requires design work to figure out what we can do to replace this functionality.

[retep998]

@DanielKeep was specifically interested in set_print as he was working on a library that automatically interprets all escape codes written to stdout and replaces them with calls to the Windows Console API.

[DanielKeep]

Currently, the code for doing this (replacing stdout) is platform-specific and really brittle (see ansi_interpreter win32/intercept.rs). It basically has to do an end-run-around behind libstd's back, swapping out the OS level handles and hoping that no one has touched IO yet... because if they have, then libstd will have already cached the "true" handles, and none of this will work.

Because of libstd's caching behaviour, the only way I can see to do this properly is to be able to explicitly replace the output writer.

Also, consider that you often want to redirect stdout/stderr when working with GUI applications, either to an internal buffer or a log file. Remember that on Windows, GUI applications don't have the standard IO handles connected to anything.

One point to note, however, is that the interception I'm doing is process-wide, whereas I believe set_print is per-thread. Both are useful, though; something like this would be handy:

fn set_process_stdout<W: Write + IntoRawFd>(write: W) -> io::Result<()> { ... }
fn set_thread_stdout<W: Write>(write: W) -> io::Result<()> { ... }

[nagisa]

The two functions in the original report were added as a short term hack and are not intended for stabilisation consideration. If the functionality is desired, an RFC with a proper proposal should be created IMO.

[SimonSapin]

If this is a short term hack, what will the test crate use long term to capture test output?

[nagisa]

What will the test crate use long term to capture test output?

What test crate is using is an implementation detail of (currently) internal component. I suppose test crate would start using the newly introduced stable functions once those become available.

I do not argue against including this sort of functionality into libstd, but to me it sounds like there should be more design process for this and the process in question happens with RFCs (e.g. one obvious solution is to have something based on dup2 on unixes).

[tomaka]

For the record, the stdout and stderr are ignored when running an Android app.
android-rs-glue is using this feature to redirect stdout/stderr to Android's logging system.

EDIT: in fact no longer the case.

[BartMassey]

For the record, see issue #35136 for an example where the test runner fouls up my test via set_print redirection.

I would prefer to see set_print and set_panic replaced by the test runner running its crates in a child process it controls, ala http://gitlab.com/BartMassey/ptyknot, but I'm not sure how that would work on Windows.

[SecondNature]

set_print() doesn't capture io through std::io::write(). Consider adding set_write() or perhaps making internal set_stdio() , if that would achieve the same result, public would provide io::write() capture.

[SimonSapin]

@SecondNature There is no write() function in std::io. Are you referring to something else? (Perhaps provide a code example?)