Learn › Linux Foundations › I/O Redirection
> - a hands-on Linux lab on a real virtual machine.
Meet the operator: point a command's stdout at a file instead of the screen. Write a file with one command, verify it with cat, discover that overwrites, then prove all of it from memory in the practice terminal.
Every command you have met so far talks to your screen. echo prints its words there. cat prints a file's contents there. The screen is the destination, always, automatically.
In this lesson you will run a command and the terminal will print nothing at all. No result, no message, just a fresh prompt. And that silence will mean it worked perfectly. The words still exist; they just went somewhere other than the screen. One character makes it happen: >, the output redirect operator. By the end you will be writing and overwriting files with it from memory.
The black boxes below are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. On the real machine at the end of the module, the capstone mission builds this same signal folder and you run these moves for real.
Here is the secret behind the silence. A command does not actually print to the screen. It writes to a stream called stdout, short for standard output. Normally the shell points stdout at your terminal window, so the text lands in front of your eyes.
That pointing is adjustable. The > operator tells the shell: for this one command, point stdout at a file instead. The command runs exactly as it always does and never knows the difference. Only the destination changes.
You will work inside the signal folder in your home directory, the small fixture folder this module uses. One boundary to set now: commands also carry a second, separate stream just for error messages, called stderr. > does not touch it, and it gets its own lesson later in this module. Today is stdout only.
Redirection is as old as Unix itself. Ken Thompson's first shell at Bell Labs understood > in the early 1970s, and the syntax has not changed in fifty years.
The shape is: a command, then >, then a filename. Here is what > does to the flow. Normally stdout runs to your screen; the > operator unbolts that wire and re-points it into a file. Watch the stream move:
{ "caption": "echo hi > out.txt: the > operator re-points stdout (the command's output stream) from the screen into a file.", "nodes": [ { "id": "cmd", "label": "echo hi", "kind": "command", "col": 0, "row": 0 }, { "id": "file", "label": "out.txt", "kind": "file", "col": 2, "row": 0 } ], "edges": [ { "from": "cmd", "to": "file", "label": "> stdout", "kind": "stdout", "stage": 1 } ] }
Time to run it. Save a greeting into a file called out.txt:
echo hi > out.txt
Before you press Enter, commit to a prediction: what will the terminal print? The word hi, or something else?
prompt: student@linuxcamp:~/signal$ answer: echo hi > out.txt output: hint: Type echo hi, then the > operator, then the filename: echo hi > out.txt
Nothing printed. If you predicted hi, here is the twist: hi was produced, but not for the screen. The > re-pointed echo's stdout into out.txt, so nothing was left over for the terminal. An empty response after a redirect is not a failure. Silence means it worked.
Something else happened quietly: out.txt did not exist before you ran that. > created it on the spot. You never need a separate make-the-file step.
A silent success still deserves proof. cat is the read-a-file command you met earlier in the course, and it is the natural partner of >: one writes the file, the other shows what is inside.
cat out.txt
Before you run it, decide exactly what you expect to see, letter for letter.
prompt: student@linuxcamp:~/signal$ answer: cat out.txt output: hi hint: cat, a space, then the filename you just wrote: cat out.txt
There it is: hi, pulled back out of the file. That round trip is the working pattern: write with >, verify with cat. Engineers lean on it daily, saving a command's output now to read or share later.
Now the one thing about > you must know before you trust it with a file you care about. Redirect a second line into the SAME file and watch what happens to the first one.
echo replaced > out.txt
Before you run it, commit to an answer: afterward, will out.txt hold two lines, hi and replaced? Or just one?
prompt: student@linuxcamp:~/signal$ answer: echo replaced > out.txt output: hint: Same > operator, new word, same file: echo replaced > out.txt
Silent again, as expected. Now read the file and check your prediction:
cat out.txt
prompt: student@linuxcamp:~/signal$ answer: cat out.txt output: replaced hint: Read it back one more time: cat out.txt
One line. The hi is gone, and it is not coming back. > does not add to a file. It empties the file first, then writes, every time, with no warning and no confirmation question.
Put your two cat runs side by side: hi became replaced. That one changed line is the most important fact about this operator, and you did not read it in a manual. You watched a line of data disappear. That is the milestone of this lesson: > replaces. When you need to keep the old lines and add more, a second operator does that, >>, and it is the very next lesson.
Scaffolding off. No command is shown from here on.
The overwrite left out.txt holding replaced. Undo it. Make the file hold exactly one line again: the word hi. Same operator, aimed the same way.
prompt: student@linuxcamp:~/signal$ answer: echo hi > out.txt output: hint: The echo command, the word hi, the redirect operator, then the filename.
Silent, and this time you knew before pressing Enter that the silence was success. The redirect emptied out replaced and wrote hi fresh, because that is what > always does: blank the page, then write.
Still no command shown. You believe the file says hi again. Prove it, letter for letter, with the read-back partner of >.
prompt: student@linuxcamp:~/signal$ answer: cat out.txt output: hi hint: The command that prints a file's contents, then the filename.
Confirmed: hi is back. Write, then verify. That two-step habit is what separates people who trust their redirects from people who discover a week later that a file holds the wrong thing.
One more, from memory. There is no file called log.txt in the signal folder yet. Create it and put a single line inside, the word first, all in one command. Remember the first drill: > does not need the file to exist.
prompt: student@linuxcamp:~/signal$ answer: echo first > log.txt output: hint: Same shape as the greeting drill: echo, the word, the operator, the new filename.
Silence again, which you now read fluently: log.txt exists and holds the line first. You created a file and filled it in one move, no editor needed. Keep that log in mind. The very next lesson picks it up and teaches >>, the operator that adds lines to the bottom instead of wiping the page.
You earned this cheat sheet. Every row is something you just ran in the signal folder:
The one idea under all of it: every command writes its normal output to stdout, and stdout normally flows to your screen. > re-points that flow into a file for one command. The file is created if missing, emptied if it exists, then written. Silence on the screen is the receipt.
If a command still prints text on your screen after you redirect it with >, you are probably looking at its error messages. Errors travel on a separate stream, stderr, that > does not touch. Later lessons in this module teach you how to catch that stream too.
You just drove > through its full range: a first write, a read-back proof, the overwrite trap, and three moves from memory, including creating a file out of thin air.
The io-redirection module ends with one real Linux machine: the redirection mission lab. There a VM boots just for you with this same signal folder, and the mission hands you objectives that use exactly what you just ran, with no commands shown. You read the objective, recall the operator, and type it. That recall is what makes it stick.
Next lesson: >>, the append operator, which adds to your new log.txt instead of wiping it. Finish the module's lessons, then go run the mission for real.
Practice The > Operator: Redirect Output to a File in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.