Terminal · foundation
Standard input, output, and error
A command-line process normally starts with three conventional open streams: standard input for incoming data, standard output for primary results, and standard error for diagnostics.
Why it matters
Keeping results separate from diagnostics lets programs feed clean data to other programs while still showing failures to a person or log.
Mental model
How to reason about standard input, output, and error
Treat file descriptors 0, 1, and 2 as independently connected byte channels whose destinations the parent process or shell can replace before execution.
Analogy
A workshop has one intake conveyor, one finished-goods conveyor, and a separate alarm channel; mixing alarms into the goods makes automation unreliable.
Examples
See the boundary, not just the happy path
Worked example · Data from standard input
wc -l < access.logThe shell connects access.log to descriptor 0, so wc reads the file's bytes through standard input without receiving the filename.
Worked example · Separate results and diagnostics
find src -name '*.dart' > files.txt 2> errors.txtSuccessful path results on descriptor 1 go to files.txt, while permission and traversal diagnostics on descriptor 2 go to errors.txt.
Useful contrast · Terminal is one possible connection
printf '%s\n' readyIn an interactive shell stdout often points at the terminal, but stdout is the channel itself and can instead point to a file, pipe, or socket.
Common mistakes
Misconceptions to remove early
Calling stdout the screen
The screen is only a common destination; stdout is an open stream whose connection can be redirected.
Printing diagnostics to stdout
Error prose mixed with machine-readable results can corrupt downstream processing; diagnostics normally belong on stderr.
Quick check
Can you predict the result?
1. Which standard stream normally carries diagnostics?
- • Standard error
- • Standard output
- • Standard input
2. Why can stdout feed either a terminal or another command?
Keep building