Standard streams (stdio)
Also: stdin · stdout · stderr · 標準輸入輸出
The three data pipes every process is born with: stdin to read from, stdout for normal output, stderr for errors — three separate channels.
When you will meet it
"Pipe the file into the program", "capture the program's output", "the error never made it into the log" — all of these bottom out in the same machinery. The classic confusion — output redirected into a file, yet the error only on screen — is because errors travel on stderr, not stdout. MCP servers can even use stdio itself as the transport to their host program.
An analogy
Like a bank counter: stdin is the form you hand over, stdout is the receipt the clerk prints, and stderr is a separate loudspeaker reserved for "something went wrong". Three channels that do not interfere — the receipt stays clean no matter how loudly the speaker shouts.
Minimal example
# 一個指令，兩條輸出管線各走各的：
ls ~ /not-exist 1>out.txt 2>err.txt
cat out.txt # 只有成功列出的家目錄內容
cat err.txt # ls: /not-exist: No such file or directory1 is stdout, 2 is stderr — fixed numbers by convention. Once you see them as two separate pipes, a family of mysteries resolves: errors still hitting the screen while output is redirected; warnings not polluting a command's JSON (they took stderr); and 2>&1 as the way to merge the two.
What people get wrong
- Reading anything printed on stderr as "the program failed". Success is decided by the exit code: many tools print warnings on stderr and still finish fine (exit 0) — just as a screen full of healthy-looking output can accompany a non-zero exit.
- Assuming a pipe carries everything to the next program. | passes only stdout by default; stderr skips the pipe and prints straight to your terminal — the "missing half of the output" usually went down the error channel.