Redirection and File Descriptors

Reviewed & published by Brayan K

By the end of this lesson you'll understand the three standard streams (stdin, stdout, stderr), how to send output to files with > and >>, how to read input from a file with <, how to separate and combine stdout and stderr (including the famous 2>&1 ordering trap), how to discard output with /dev/null, and how to use here-documents, here-strings, and tee.

Part of the free Command Line course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• Name the three file descriptors: 0 stdin, 1 stdout, 2 stderr
• Redirect stdout with > (truncate) and >> (append)
• Read input from a file with < and feed one string with <<<
• Redirect stderr with 2> and merge streams with 2>&1 and &>
• Discard output with /dev/null without stopping the command
• Write config with here-documents and split output with tee

1. The Three Standard Streams

Every command is born with three open streams, each identified by a number: 0 is stdin (the input it reads), 1 is stdout (its normal output), and 2 is stderr (its error messages). By default all three are wired to your terminal, which is why normal output and errors appear mixed together — but they are genuinely separate channels, and that separation is what every redirection below exploits.

# Every command starts life with three open streams, each with a number:
#   0  stdin   — where it READS input from (default: the keyboard)
#   1  stdout  — where it WRITES normal output (default: the terminal)
#   2  stderr  — where it WRITES error messages (default: the terminal)

# Make a file that exists, so this runs the same on any machine.
printf 'my-machine\n' > hostname.txt

# 'ls' on a file that exists prints a NORMAL line on stdout (fd 1).
# 'ls' on a missing file prints an ERROR line on stderr (fd 2).
#
# Run it on both at once and the terminal blends the two, so it LOOKS
# like one stream — and which line lands first is not fixed. Send stderr
# to a file instead and the separation becomes visible AND repeatable:
ls hostname.txt /no/such/file 2> errors.txt

echo "--- everything above came from stdout (fd 1) ---"
cat errors.txt
echo "--- and that line came from stderr (fd 2) ---"

2. Sending stdout to a File: > and >>

The > operator redirects stdout into a file. It truncates the file first (emptying it, or creating it if it does not exist), so the file ends up containing only what that one command wrote. The >> operator instead appends to the end of the file, preserving what was already there — perfect for a growing log.

# >  redirects stdout (fd 1) to a file. It TRUNCATES the file first
# (or creates it if it doesn't exist) — so the file ends up holding
# ONLY what this command wrote.
echo "first line"  > log.txt
echo "second line" > log.txt   # truncates again — "first line" is gone!
cat log.txt

echo "--- now with >> (append) ---"

# >> APPENDS to the end instead of truncating. Nothing is erased.
echo "line A" >  notes.txt      # start fresh
echo "line B" >> notes.txt      # add to the end
echo "line C" >> notes.txt      # add again
cat notes.txt

3. Reading stdin from a File: <

The < operator redirects stdin so a command reads from a file instead of the keyboard. Many tools (sort, wc, grep) read whatever arrives on stdin, so sort < file sorts the file's lines. This is subtly different from passing the filename as an argument: with < the shell opens the file and hands the command an already-open input stream.

# First build a small file to read FROM.
printf 'pear\napple\ncherry\n' > fruit.txt

# <  redirects stdin (fd 0): the command reads the FILE instead of
# the keyboard. Here 'sort' reads fruit.txt and sorts the lines.
sort < fruit.txt

echo "--- count the lines the same way ---"
# wc -l counts lines on whatever arrives on stdin.
wc -l < fruit.txt

4. Errors and the 2>&1 Ordering Trap

Use 2> to redirect stderr alone. To merge the streams, 2>&1 tells the shell "send fd 2 to wherever fd 1 points right now" — the &1 means the current target of stdout, not a file named 1. Because redirections are applied left to right, command > file 2>&1 sends both to the file, but the reversed command 2>&1 > file sends only stdout to the file and leaves stderr on the terminal — the classic gotcha.

# 2>  redirects ONLY stderr (fd 2). stdout still goes to the terminal.
# Here the good filename prints on the terminal; the error goes to err.txt.
ls /etc/hostname /no/such/file 2> err.txt
echo "--- what landed in err.txt: ---"
cat err.txt

echo "--- combine streams: > file 2>&1 (BOTH to the file) ---"
# 2>&1 means "send fd 2 to wherever fd 1 points RIGHT NOW".
# Order matters: > out.txt moves stdout to the file FIRST, then 2>&1
# points stderr at that same file. So BOTH end up in out.txt.
ls /etc/hostname /no/such/file > out.txt 2>&1
cat out.txt

echo "--- the GOTCHA: 2>&1 > file (only stdout to the file) ---"
# Reversed order. 2>&1 first copies stdout's CURRENT target (still the
# terminal), THEN > only.txt moves stdout. stderr was already aimed at
# the terminal, so it prints here and only stdout lands in the file.
ls /etc/hostname /no/such/file 2>&1 > only.txt
echo "--- only.txt has stdout alone: ---"
cat only.txt

5. Discarding Output: /dev/null and &>

/dev/null is the system's discard sink: anything written to it is thrown away. Redirect to it to silence streams you do not care about — 2> /dev/null hides errors, > /dev/null hides normal output. The bash shorthand &> sends both stdout and stderr at once, so &> /dev/null runs a command completely silently (it is the same as > /dev/null 2>&1). The command still runs and still sets $?.

# /dev/null is the "black hole" — anything written to it is discarded.

# Throw away ERRORS only, keep normal output on the terminal:
ls /etc/hostname /no/such/file 2> /dev/null

echo "--- throw away normal output, keep only errors ---"
# Send stdout to the void; stderr still reaches the terminal.
ls /etc/hostname /no/such/file > /dev/null

echo "--- silence EVERYTHING with the bash shorthand &> ---"
# &> file sends BOTH stdout and stderr to one place. &> /dev/null is the
# usual way to run a command completely silently. It equals > /dev/null 2>&1.
ls /etc/hostname /no/such/file &> /dev/null
echo "exit status was: $?"   # 2 — the command still RAN and failed, just quietly

6. Here-Documents, Here-Strings, and tee

A here-document (<<EOF ... EOF) feeds several literal lines into a command as stdin — ideal for writing a config file with cat > file <<EOF. Quote the delimiter (<<'EOF') to switch off variable and command expansion. A here-string (<<< "text") feeds a single string as stdin without a temp file. And tee duplicates stdin: it writes to a file and passes the text through to stdout, with -a to append.

# A here-document feeds several fixed lines into a command as stdin,
# between <<EOF and a line that is exactly EOF. Here we write a file.
name="Ada"
cat > greeting.txt <<EOF
Hello, ${name}!
Today's shell is $0.
EOF
cat greeting.txt

echo "--- quoted delimiter <<'EOF' disables expansion ---"
# Quote the word (<<'EOF') and NOTHING is expanded — ${name} and $0
# are written literally.
cat <<'EOF'
Literal: ${name} and $0 are NOT expanded.
EOF

echo "--- here-string <<< feeds one string as stdin ---"
# <<< sends a single string straight into the command's stdin.
wc -w <<< "one two three four"

echo "--- tee writes to a file AND passes the text through ---"
# tee duplicates stdin: it writes to the file and ALSO to stdout, so the
# next stage (or your screen) still sees it. -a appends instead of truncating.
echo "saved + shown" | tee copy.txt
echo "appended too"  | tee -a copy.txt
echo "--- copy.txt now holds both lines: ---"
cat copy.txt

🎯 Your Turn: append without erasing

Fill in the one blank marked ___ using the # 👉 hint so the second line is added rather than overwriting the file, then run it and check the Output panel matches.

# 🎯 YOUR TURN — add a line WITHOUT erasing the file.

echo "log started" > app.log     # creates the file with one line

# 1) Append a second line so "log started" is KEPT.
echo "user logged in" ___ app.log   # 👉 replace ___ with  >>

cat app.log

# ✅ Expected output:
#    log started
#    user logged in

🎯 Your Turn: capture both streams

Send both the normal output and the error message into one file. Put the redirection in the correct order, fill in the blank, then run it.

# 🎯 YOUR TURN — capture BOTH stdout and stderr in one file.

# 1) Send stdout to all.txt, then point stderr at the SAME place.
ls /etc/hostname /no/such/file > all.txt ___   # 👉 replace ___ with  2>&1

echo "--- all.txt should contain the error AND the good line: ---"
cat all.txt

# ✅ Expected output:
#    --- all.txt should contain the error AND the good line: ---
#    ls: cannot access '/no/such/file': No such file or directory
#    /etc/hostname

Pro Tips

• 💡 Remember the order rule as "redirect, then merge". Put > file first and 2>&1 last so stderr inherits the file. Reversed, 2>&1 > file only captures stdout.
• 💡 &> file and &>> file are bash shorthands for both streams (truncate / append). They are clearer than > file 2>&1 when you do not need portability to plain sh.
• 💡 Use tee to watch and save at once: ./build.sh 2>&1 | tee build.log shows the run live and keeps a full copy (errors included) in the log.
• 💡 Quote the heredoc delimiter (<<'EOF') whenever the body contains literal $ signs — for example when writing a script or a Dockerfile — so nothing gets expanded by accident.

Common Errors (and the fix)

• I redirected with > and lost my file's contents — a single > truncates before writing. Use >> to append instead.
• My errors still print to the screen even though I wrote 2>&1 > file — the order is backwards. 2>&1 copied stdout's target (the terminal) before > file moved stdout. Write > file 2>&1 so both go to the file.
• I expected a file named 1 — 2>1 (no ampersand) literally creates a file called 1. You almost always want 2>&1, where &1 means "the current target of fd 1".
• My here-document never ends / "unexpected end of file" — the closing delimiter must be on its own line with nothing after it (and, by default, no leading spaces). Make the final EOF match the opening word exactly.
• $variables in my heredoc came out literally — you quoted the delimiter (<<'EOF'), which disables expansion. Use an unquoted <<EOF if you want $name expanded.

📋 Quick Reference

Mini-Challenge: capture a build log

No blanks this time — just a brief and an outline. Combine a here-document, stream merging with the right order, /dev/null, and tee into a few commands that demonstrate everything from this lesson, and check your output against the hints in the comments.

# 🎯 MINI-CHALLENGE: a tiny build-log capture
# Write a few commands (or a small script) that:
#
# 1. Uses a here-document (<<EOF) to write three fixed lines into
#    report.txt, then cat it back.
# 2. Runs  ls realfile missingfile  and captures BOTH stdout and
#    stderr into build.log using  > build.log 2>&1  (note the ORDER).
# 3. Repeats the same ls but this time DISCARDS errors with 2> /dev/null
#    while still showing the good line on screen.
# 4. Uses  tee -a  to append a "done" line to build.log while also
#    printing it to the terminal.
#
# Hint: remember  > file 2>&1  puts both in the file, but
#       2>&1 > file  leaves stderr on the terminal.

# your commands here

🎉 Lesson Complete!

• ✅ The three streams are 0 stdin, 1 stdout, and 2 stderr
• ✅ > truncates and >> appends stdout; < reads stdin from a file
• ✅ 2> redirects errors; > file 2>&1 captures both, but 2>&1 > file does not (order matters)
• ✅ /dev/null discards output and &> is bash shorthand for both streams
• ✅ Here-documents and here-strings feed stdin, and tee writes to a file while passing text through

Practice quiz

Continue this course

• Previous: Command Substitution and Expansion
• Next: Finding Files with find and xargs — Search by name, type, size and time, then act in bulk with xargs
• Quick reference: Command Line cheat sheet › Pipes & Redirection

Frequently asked questions

What are file descriptors 0, 1, and 2?

They are the three streams every command opens automatically. 0 is standard input (stdin), where the command reads input from. 1 is standard output (stdout), where it writes normal results. 2 is standard error (stderr), where it writes error and diagnostic messages. Keeping stdout and stderr on separate numbers is what lets you redirect normal output and errors to different places.

What is the difference between > and >> ?

Both redirect stdout to a file, but > truncates the file first (it empties it, or creates it if missing) so the file ends up holding only what the new command wrote. >> appends to the end of the file instead, preserving whatever was already there. Use > to start fresh and >> to keep adding, such as to a growing log.

What does 2>&1 actually mean, and why does order matter?

2>&1 says 'make stderr (fd 2) go to wherever stdout (fd 1) is pointing right now'. The &1 refers to the current target of fd 1, not a file named 1. Because the shell applies redirections left to right, command > file 2>&1 first moves stdout to the file and then points stderr at that same file, so BOTH land in the file. But command 2>&1 > file copies stdout's target (still the terminal) onto stderr first, then moves only stdout to the file, so stderr keeps printing to the terminal.

How do I throw away output I don't care about?

Redirect it to /dev/null, the system's discard sink. command > /dev/null drops normal output, command 2> /dev/null drops only error messages, and command &> /dev/null (bash shorthand for > /dev/null 2>&1) drops everything and runs the command completely silently. The command still runs and still sets an exit status; you just don't see its text.

When should I use a here-document, a here-string, or tee?

Use a here-document (<<EOF ... EOF) to feed several fixed lines into a command as stdin, for example to write a config file with cat > file <<EOF. Quote the delimiter as <<'EOF' to stop variable and command expansion. Use a here-string (<<< "text") to feed a single string as stdin without a temp file. Use tee when you want output written to a file AND passed through to the screen or the next command at the same time; add -a to append rather than overwrite.