How do you capture what a Go function writes to os.Stdout in a test using os.Pipe?

## What os.Pipe gives you `os.Pipe()` returns `(r *os.File, w *os.File, err error)`: a kernel pipe with real file descriptors, presented as two files. Bytes written to `w` are readable from `r`. Because both ends are genuine `*os.File` values, they can stand in anywhere a file is expected - including as the value of `os.Stdout`. That is different from a purely in-process reader/writer pairing: `os.Pipe` costs a system call and gives you descriptors the kernel knows about, which is exactly what you need when the thing you want to intercept writes to descriptor 1. ## The capture pattern ```go r, w, err := os.Pipe() if err != nil { t.Fatal(err) } old := os.Stdout os.Stdout = w done := make(chan []byte, 1) go func() { b, _ := io.ReadAll(r) done <- b }() printReport() // the code under test w.Close() os.Stdout = old got := string(<-done) ``` Four things are load-bearing: 1. **`os.Stdout` is a variable.** Assigning to it is what makes the interception work; nothing else in the program needs to change. 2. **The reader runs concurrently.** A pipe has a fixed kernel buffer - tens of kilobytes on Linux. Once it is full, `write` blocks until someone reads. If your only read happens after `printReport()` returns, and `printReport` prints more than the buffer holds, it never returns. The test hangs until the package timeout, and the panic dump shows a goroutine blocked in a write, which is a confusing trail to follow if you did not expect it. 3. **Closing `w` ends the read.** `io.ReadAll(r)` returns when the pipe reports end of file, and that happens when the last write end is closed. Forget the `Close` and the reading goroutine blocks forever and the channel receive never completes. 4. **Restore the old value.** Leaving `os.Stdout` pointed at a closed pipe breaks every later test in the package, usually in a way that looks unrelated to the test that caused it. ## Why this is a last resort - **It is process-global.** Two tests doing it at once, or one doing it under `t.Parallel`, race on the same variable. The whole capture must be serial. - **It only catches code that reads `os.Stdout` at call time.** A package that did `var out io.Writer = os.Stdout` at initialisation captured the original file and writes straight past your pipe. - **It is slow and fiddly** compared to the alternative, and the failure mode when you get it wrong is a hang rather than a clear error. ## The design that removes the need A function that takes its destination as a parameter is trivially testable: ```go func printReport(w io.Writer, r Report) error ``` In production the caller passes `os.Stdout` (or a `bufio.Writer` over it); in a test it passes a `bytes.Buffer` and asserts on `buf.String()`. No globals, no pipe, no goroutine, and it runs happily under `t.Parallel`. Threading the writer down from `main` also removes the temptation for library code to decide where output goes - a decision only the program should make. So the honest answer to the interview question is both halves: here is the pipe technique, precisely, for code you cannot change; and here is why the code you own should never need it. ## Other legitimate uses of os.Pipe The same primitive appears wherever something needs a real descriptor rather than an in-memory writer - handing one end to a subprocess, or giving a C library a file to write into. Whenever you use it, the same two rules apply: someone must be reading while someone is writing, and the write end must be closed for the reader to see the end of the stream.