Learn › Linux Foundations › I/O Redirection
/dev/null - a hands-on Linux lab on a real virtual machine.
Meet /dev/null, the null device that destroys everything written to it. Shred a command's errors with 2/dev/null, keep only the errors with /dev/null, silence a command completely with /dev/null 2&1, and learn when to file a stream instead of shredding it.
Somewhere on every Linux machine there is a file that has swallowed more text than every other file on the system combined. Scripts pour thousands of lines into it every hour. It never grows by a single byte. Read it right now and it is empty. Read it after a year of nonstop writing and it is still empty.
The file is called /dev/null. In this lesson you learn why engineers write to a file that keeps nothing, and why you will end up doing it almost every day.
You will work inside the signal folder in your home directory, with the same report.sh status script you have been steering all module.
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.
/dev/null is a device file. A device file is a file that stands for a piece of equipment instead of data on a disk, and /dev is the folder where Linux keeps them. The equipment behind /dev/null is nothing at all, which is exactly the point. It is called the null device.
Its contract has two halves. Anything written to it is accepted and destroyed in the same instant; nothing is stored, so it never grows and never fills a disk. And anything that tries to read from it gets nothing back, because it is permanently empty.
Here is what makes this lesson easy: there is no new operator today. You already own the tools. > redirects stdout, 2> redirects stderr, and &> and 2>&1 handle both streams, all from earlier lessons in this module. /dev/null is a destination. Aim any stream at it with an operator you know, and that stream is destroyed instead of saved.
One word pair to carry through this lesson. 2> errors.txt FILES a complaint, and you can read it later. 2>/dev/null SHREDS it, gone forever. Same operator, different destination.
The null device has been part of Unix since the early 1970s, and engineers have nicknamed it the bit bucket ever since: the bucket where unwanted bits go to disappear.
Start with the smallest possible experiment. Remember from the > lesson: echo hi > out.txt prints nothing, and the word lands in out.txt, one cat away from being read back.
Now run the same redirect aimed at the null device:
echo hi > /dev/null
Before you press Enter, commit to two predictions. What will the terminal print? And where will the word hi be afterward?
prompt: student@linuxcamp:~/signal$ answer: echo hi > /dev/null output: hint: The > operator you already know, aimed at the null device: echo hi > /dev/null
Silence, exactly like any other > redirect. The difference is the second prediction. With out.txt, the word was sitting in a file, ready to be read back. This time there is nothing to read back from anywhere. /dev/null accepted the write and destroyed it on arrival. No file grew, and there is no undo and no trash bin. That is the contract: whatever goes in never comes out.
Now the real work. report.sh prints two routine lines on stdout and one complaint, report: sensor offline, on stderr. In the 2> lesson you filed that complaint into errors.txt. Suppose you already know the sensor is offline and you are tired of hearing about it. Do not file the complaint. Shred it.
bash report.sh 2>/dev/null
Three lines want to reach your screen. Before you run it, decide which of them will survive.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh 2>/dev/null output: report: system nominal report: all checks passed hint: Aim channel 2 at the void: bash report.sh 2>/dev/null
The two routine lines survived and the complaint did not. Compare this with the 2> lesson's move. 2> errors.txt also cleaned your screen, but it left a file behind holding the complaint. 2>/dev/null leaves nothing: no noise on screen, no file to clean up later. Shredding is the right choice when a complaint is known, harmless, and useless to keep.
Here is where working engineers type /dev/null most. A command does its job but also complains about something you already know. ls fruits.txt nowhere.txt is the example you met in the 2> lesson: the found name travels on stdout, and the complaint about the missing file travels on stderr.
You want the answer without the noise. Before you run it, decide exactly what will appear on your screen.
ls fruits.txt nowhere.txt 2>/dev/null
prompt: student@linuxcamp:~/signal$ answer: ls fruits.txt nowhere.txt 2>/dev/null output: fruits.txt hint: Same shred move, on ls this time: ls fruits.txt nowhere.txt 2>/dev/null
Just fruits.txt, the real answer, with the complaint dissolved. That little suffix, 2>/dev/null, may be the most-typed redirect in real operations. Engineers bolt it onto searches that hit permission walls, onto scripts that probe for files that may not exist, onto any command whose complaints are already understood. That is the milestone of this lesson: you can now silence any command's error channel on demand.
One honest warning comes with the power. The shredder cannot tell a boring complaint from a brand-new disaster; 2>/dev/null destroys both. Quiet a command only when you know what you are throwing away.
Flip the aim. A bare > with no 2 in front redirects stdout, channel 1, and leaves stderr alone. So point the RESULTS at the void this time:
bash report.sh >/dev/null
The same three lines are coming. Before you run it, commit: which line survives now?
prompt: student@linuxcamp:~/signal$ answer: bash report.sh >/dev/null output: report: sensor offline hint: A bare > aimed at the void redirects stdout only: bash report.sh >/dev/null
Exactly one line survived, and it is the complaint. Put the last two drills side by side and the lesson teaches itself. 2>/dev/null left the two routine lines. >/dev/null left only the error. Same script, opposite stream aimed at the void, and what remains on screen proves which channel every line was riding.
This mirror is a real pattern with a name: no news is good news. Run a chatty script with its stdout shredded and your screen stays blank while everything is fine. The moment something breaks, the error lands in front of you with nothing to bury it.
And when you want NOTHING to survive, aim both streams at the void. Point stdout there first, then fold stderr into it with the merge you learned last lesson: bash report.sh >/dev/null 2>&1. The bash shorthand &>/dev/null does the same job in fewer characters. Scripts that run unattended use this constantly, because no screen is watching them anyway.
Scaffolding off. No command is shown from here on.
Run the status report so only its two routine lines reach the screen. The complaint must not appear, and it must not be saved anywhere either.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh 2>/dev/null output: report: system nominal report: all checks passed hint: The report runs with bash report.sh. Aim its error channel, number 2, at the null device.
Two lines, no complaint, no file left behind. Filing it would have been 2> errors.txt. You shredded instead, because the goal said save nothing.
Reverse it. Run the report so the ONLY thing on your screen is the problem line. The routine chatter must vanish, and nothing may be written to any file.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh >/dev/null output: report: sensor offline hint: Aim the normal output stream, stdout, at the void and leave channel 2 alone.
Only the complaint survives. That is monitoring in one line: silence while things work, a message the moment they do not.
The final move combines two lessons. Run the report so absolutely nothing appears on screen: both streams destroyed, no files written, just a clean prompt when it finishes.
prompt: student@linuxcamp:~/signal$ answer: bash report.sh >/dev/null 2>&1 ||| bash report.sh &>/dev/null ||| bash report.sh >/dev/null 2>/dev/null ||| bash report.sh 2>/dev/null >/dev/null output: hint: Two aims in one line: stdout to the void first, then the merge operator that sends channel 2 wherever channel 1 points. The bash shorthand for both streams works too.
A bare prompt, and this time you know the silence is total: both channels poured into the null device and nothing was kept. If you wrote the long form, notice the order, >/dev/null first and 2>&1 second. Remember the rule from the merge lesson: 2>&1 sends stderr to wherever stdout points at that moment, so stdout must already point at the void when the merge happens. Reversed, the complaint would still hit your screen.
You earned this cheat sheet. Every row is a move you just ran in the signal folder:
The one idea under all of it: /dev/null is not an operator, it is a destination. The null device accepts every write, stores nothing, and reads back empty, forever. Choose it as a target when a stream has no value, and choose a real file when it does.
The shredder takes everything, including errors you have never seen before. When a silenced command starts misbehaving, your first debugging move is always the same: delete the /dev/null redirect, run the command again, and read what it has been trying to tell you.
You just ran the null device through its full range: a word into the void, errors shredded while results survived, the no-news mirror image, and three moves from memory, ending in total silence.
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 pipe, which aims a stream at another command instead of a file. Finish the module's lessons, then go run the mission for real.
Practice The Null Device: /dev/null in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.