`tee` Is How You Stop Choosing Between Seeing Output Now and Saving It for Later

The quiet frustration this solves: one command produces useful output, but you either watch it scroll by and lose it or redirect it to a file and lose the live view. tee exists to end that unnecessary tradeoff.

What tee does

The GNU Coreutils manual describes tee as reading from standard input and writing to standard output and files. That is exactly the reason it is so handy. It duplicates a stream.

The usual pattern:

some-command | tee output.log

Now you can see the output in the terminal and also save it to output.log.

That sounds small, but it is a real workflow improvement in debugging, CI reproduction, and local testing.

Why redirection alone is not enough

If you do:

some-command > output.log

you save the output, but you no longer see it live.

If you do not redirect at all, you can see it live but may lose it once it scrolls away or once you need to share it later.

tee is the clean middle path.

Good use cases for developers

It is especially useful when:

1. you want to capture build output while watching for failures
2. you are collecting logs from a reproduction step
3. you want to save API responses or generated reports
4. you need an artifact to attach to a bug report

This is why tee belongs in muscle memory. It fits those in-between situations where visibility and preservation both matter.

Overwrite versus append

Basic tee writes a fresh file:

some-command | tee output.log

Append instead:

some-command | tee -a output.log

This distinction matters more than people think. Appending is useful for repeated test runs or growing logs. Overwriting is cleaner when each run should stand alone.

A practical debugging example

Suppose you are reproducing a flaky install:

npm install 2>&1 | tee install.log

Now stderr and stdout both go into the log while still appearing live in the terminal. That is much better than trying to rerun the failure later because you forgot the exact warning sequence.

The 2>&1 part matters because many useful diagnostics are emitted on stderr rather than stdout.

Why this is better than copying terminal history

Developers sometimes wait until something fails, then scroll back and manually copy the interesting part. That works until:

1. the output was too long
2. the terminal buffer was not enough
3. the sequence mattered more than one isolated line

tee is better because it makes preservation part of the command from the start instead of an emergency task afterward.

A broader workflow lesson

Good debugging often means creating evidence while the system is still misbehaving. tee supports that mindset. It is not a glamorous tool, but it helps you move from “I saw something weird” to “I have the exact output from the failing run.”

Final recommendation

Use tee whenever live visibility and later review both matter. It is one of the simplest ways to make shell workflows more dependable, especially for build logs, repro steps, and anything you may need to share with someone else later.

Sources

• GNU Coreutils manual