Saving output to files

How do you save a command's output to a file?

Put > and a file name at the end of the command. The output that would have appeared on screen goes into the file instead. If the file doesn't exist, the shell creates it.

Nothing prints when you do this, which can feel as if nothing happened. Check the result with cat waiting.txt or wc -l waiting.txt, or click the new file in the Files view. Any command that prints text can be saved this way: ls, grep, sort, a whole pipeline.

In a pipeline, the > goes at the very end, after the last command. It saves whatever the last stage prints.

grep waiting orders.csv > waiting.txt
wc -l waiting.txt
7 waiting.txt

Why is > dangerous?

> replaces the whole file. The shell empties the file first, before the command even starts, and then writes the new output into it. If you meant to add a line to the shop log and typed one >, every earlier entry is gone. There's no undo and no recycle bin on the command line.

A worse version catches people who sort a file "in place". sort prices.csv > prices.csv looks reasonable, but the shell empties prices.csv before sort opens it, so sort reads an empty file and you end up with nothing. The practice terminal does the same, so try it here and see prices.csv come back empty. Always write to a new name and rename it afterwards if you need to.

Bash can protect you: set -o noclobber makes > refuse to overwrite an existing file, and you write >| when you really mean it. Some people put it in their settings file. Either way, check file names twice before pressing Enter on a line with > in it.

sort -t, -k2 -n prices.csv > prices-by-cost.csv
mv prices-by-cost.csv prices.csv

How do you add to the end of a file?

Use >>. It opens the file and writes after whatever is already there. If the file doesn't exist yet, it creates it, the same as >.

>> is the right choice for anything that grows over time: a log, an archive of daily specials, a list of walk dates. Pair it with echo to write a single line, or with date to stamp when something happened.

echo "2026-03-14 waiting list saved" >> log.txt
cat log.txt
2026-03-13 opened late, oven repair
2026-03-14 waiting list saved

Where do error messages go?

Commands have two output streams. Standard output, stream 1, carries normal results. Standard error, stream 2, carries complaints and warnings. Both show on screen, so they look the same, but > only redirects stream 1. Errors pass straight through to the screen.

To catch errors, put the stream number in front: 2> errors.txt. That's handy in scripts that run without anyone watching, where an error file shows what went wrong later. Separating them also keeps a saved list clean: ls *.csv > list.txt 2> errors.txt puts the file names in one place and the problems in another.

You can throw errors away with 2> /dev/null, a special file that discards everything written to it. It works in the practice terminal too.

ls till-export.csv 2> errors.txt
cat errors.txt
ls: cannot access 'till-export.csv': No such file or directory

What does 2>&1 mean?

2>&1 means "send stream 2 to wherever stream 1 is going right now". It merges errors into normal output so both travel together. Its most common use is to pass errors along a pipe, where they would otherwise skip past the next command and land on screen:

command > all.txt 2>&1 saves both streams into one file. Order counts: the shell reads redirections left to right, so > all.txt must come before 2>&1. Written the other way round, errors still go to the screen. The practice terminal follows the same order, so you can try both versions and compare all.txt.

Bash also has a short form, &> all.txt, which saves both streams. It works in bash and zsh but not in every shell, so scripts meant to run anywhere use the longer form.

ls till-export.csv orders.csv 2>&1 | grep -c csv
2

How do you see output and save it at the same time?

tee copies its input to the screen and into a file. Put it at the end of a pipeline when you want to check the result and keep it. Add -a to append instead of overwrite, the tee version of >>.

tee also helps in the middle of a pipeline: grep waiting orders.csv | tee waiting.txt | wc -l saves the full list and prints the count, in one line.

grep waiting orders.csv | tee waiting.txt | wc -l
7

What does < do?

< points the other way: it feeds a file into a command's standard input. wc -l < orders.csv prints 13 with no file name after it, because wc only sees a stream of text and doesn't know where it came from. That's useful when you want a bare number to use somewhere else.

Most commands take a file name anyway, so < comes up less often than >. You'll see it in scripts and with commands that only read input, such as tr.

You can combine < and > on one line. sort < tally.txt > tally-sorted.txt reads one file and writes another, and the original stays untouched. The order of the two redirections on the line makes no difference here, because they point at different streams.

wc -l orders.csv
13 orders.csv

wc -l < orders.csv
13

What do AI tools get wrong with redirection?

Watch for > where >> was meant, especially in commands that write to logs, .bashrc or settings files. A suggested echo 'export PATH=...' > ~/.bashrc replaces your whole settings file with one line. It should be >>.

Also watch for output written back to its own input file, 2>&1 placed before >, and 2> /dev/null added to hide errors you need to see. Hidden errors make a failed command look as if it worked. Read every > in a suggested command and ask which file it will empty.

A good habit before any redirect is to run the command once without it and read what it prints. If the output on screen is what you want in the file, add the > or >> and run it again. That one extra step catches most mistakes before they reach a file you care about.

Field notes

• > sends output into a file and replaces whatever was in it.
• >> adds to the end of a file and keeps what is already there.
• Error messages travel on a separate stream, number 2.
• 2> saves error messages into a file instead of the screen.

Easy to get wrong

A single > empties the log before writing, so every earlier entry is lost. >> adds to the end.

The shell empties prices.csv before sort reads it, leaving an empty file. Write to a new name.

> only catches normal output. Error messages use stream 2, so they need 2>.

Redirections apply left to right. 2>&1 first points errors at the screen, then > moves only normal output to the file.

Questions people ask

Can I undo a > that overwrote a file?

Not from the shell. Restore from a backup or from version control such as Git if the file was in it. That's why it pays to check the file name before pressing Enter.

Does > work with any command?

Yes, with any command that prints to standard output. Commands that print nothing, like cd or mkdir, just create an empty file.

Why is my saved file empty?

Either the command printed nothing (grep found no match), or the message you saw was an error, which > doesn't catch. Run the command without > and see what it prints.

Is redirection the same on a Mac?

Yes. zsh uses the same >, >>, 2>, 2>&1, < and tee. One difference: zsh turns on overwrite protection with setopt noclobber instead of bash's set -o noclobber, and accepts >! as well as >| to override it.