Redirection
Redirection rewires the standard streams before a command starts: > truncates stdout to a file, >> appends, < feeds a file into stdin, 2> captures stderr, and 2>&1 merges stderr into stdout. Order of operators matters.
You know that commands write to stdout and stderr and read from stdin. What if you want to save that output to a file instead of watching it scroll by? Or feed a file’s content into a command as if you had typed it? That’s redirection — the shell’s ability to rewire file descriptors before the command ever starts running. It’s one of the most useful things you can do at the shell, and the syntax is compact once you see the pattern.
By the end of this lesson you will be able to redirect stdout and stderr to files, append instead of overwrite, feed files into stdin, and — critically — understand why 2>&1 must come after >, not before.
After this lesson you can use > to truncate stdout to a file, >> to append, < to feed a file into stdin, 2> to capture stderr, and 2>&1 to merge stderr into stdout. You understand the ordering rule for combined redirections.
> redirects stdout to a file, truncating it first. The shell opens the target file (creating it if needed, truncating it to zero bytes if it exists) and replaces fd 1 with that file before executing the command. The command writes as normal — it doesn’t know it’s writing to a file.
ls /etc > /tmp/etc-list.txtNo output appears on screen. /tmp/etc-list.txt now contains what ls /etc would have printed. If the file already had content, > destroys it.
echo "first" > /tmp/demo.txt
echo "second" > /tmp/demo.txt
cat /tmp/demo.txtsecondThe second > wiped out “first”. If you want to keep both, you need >>.
>> appends stdout to a file. The shell opens the file in append mode — existing content is preserved and new data is added at the end.
echo "first" > /tmp/demo.txt
echo "second" >> /tmp/demo.txt
cat /tmp/demo.txtfirst
second>> is the safe way to accumulate output across multiple commands or runs of the same script.
< redirects stdin from a file. The shell opens the file and replaces fd 0 with it. The command reads from fd 0 as usual — it doesn’t know the bytes are coming from a file instead of a keyboard.
wc -l < /etc/passwdwc -l counts lines. With < /etc/passwd, it reads from the file instead of waiting for keyboard input. This is equivalent to wc -l /etc/passwd for most tools, but some tools only read from stdin (not from a filename argument), making < essential.
2> redirects stderr to a file. Just as > is shorthand for 1> (redirect fd 1), 2> redirects fd 2.
ls /exists /nonexistent 2> /tmp/errors.txtNormal output from /exists prints to the terminal. The error about /nonexistent goes silently into /tmp/errors.txt. You can check errors later without them cluttering the screen.
A common use: discard errors entirely with the special null device:
ls /nonexistent 2> /dev/null/dev/null is a device that silently discards everything written to it. This is the Unix way of saying “suppress error messages.”
2>&1 merges stderr into stdout — but order matters. The notation N>&M means “make fd N point to the same place fd M currently points.” So 2>&1 means “make stderr point to wherever stdout is pointing right now.”
ls /exists /nonexistent > /tmp/all.txt 2>&1The shell processes redirections left to right:
> /tmp/all.txt— fd 1 now points to/tmp/all.txt.2>&1— fd 2 now points to wherever fd 1 points, which is/tmp/all.txt.
Result: both stdout and stderr go into the file.
The classic mistake is reversing the order:
ls /exists /nonexistent 2>&1 > /tmp/all.txtThis is wrong. The shell reads left to right:
2>&1— fd 2 is set to point to wherever fd 1 currently points, which is still the terminal.> /tmp/all.txt— fd 1 is now redirected to the file.
Result: stdout goes to the file, stderr still goes to the terminal. The merge happened before the file redirect took effect.
Capture all output — stdout and stderr — into a single log file.
A build script produces both normal output and error messages. You want everything in one file for later review:
make 2>&1 | tee build.logOr without a pipe, just to a file:
make > build.log 2>&1After the run, build.log contains everything. To check only errors:
grep -i error build.logNow try the wrong order to see the difference:
make 2>&1 > build.logErrors from make still print to the terminal; only stdout goes to build.log. Remembering “stdout redirection first, then merge” prevents this footgun.
▸Why this works
On macOS/BSD, all these redirection operators work identically — they are POSIX shell syntax, not Linux-specific. /dev/null also exists on macOS. The only macOS difference worth noting: some macOS utilities behave slightly differently when given filename arguments vs stdin, but the redirection operators themselves are identical.
▸Common mistake
Forgetting 2>&1 when you want a truly complete log is the single most common redirection mistake. A command can look successful in a log while silently printing errors to the terminal. Always check: “did I capture both streams?” If you want everything in one place: command > file 2>&1. If you want them in separate files: command > out.txt 2> err.txt.
You run: cmd > out.txt 2>&1. Where does stderr go?
Redirection rewires file descriptors before a command starts. > truncates stdout to a file; >> appends. < feeds a file into stdin. 2> captures stderr. 2>&1 copies fd 2 to point wherever fd 1 currently points — so it must come after any stdout redirect if you want both streams going to the same place. The shell processes all redirections left to right before the process runs. Master the ordering rule for 2>&1 and you’ll never lose error output again.
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.