The null device in Unix systems is /dev/null.
Its purpose is to immediately discard anything sent to it.
In this guide we will discuss what is the purpose of /dev/null, why it exists, and how to use it.
Table of Contents
Virtual Devices in Linux
In Linux operating systems there are virtual devices that are used for numerous purposes.
[powerkit_alert type=”info” dismissible=”false” multiline=”false”]
Virtual devices act like they are real devices.
They are in fact files that the operating system interprets as real devices to act its function.
[/powerkit_alert]
Applications and utilities can feed and retrieve data from these files, from these “devices” to use in whatever way they are programmed to.
Null Device in Linux
One such device in Linux is the null device.
In the command line and bash scripts and other places in the operating system this null device is written as /dev/null.
Every single Linux distribution has the null device present. It’s one of those heritage functions of Unix systems adopted into Linux, and carried on by every single Linux distribution.
As opinionated as some Linux distributions are as to what to include and what to leave out, the fact that every single distro makes use of /dev/null is a testament of how important this function is.
Think about it, every single home needs to discard the garbage out in order to keep it clean and organized, right?
The null device in Linux is the one tool we can invoke to perform this discarding function and keep our operating system tidy.
Standard input (stdin), standard output (stdout) and standard error (stderr)
We have to grasp a concept of Linux computing before we can proceed to understand why we need the function of /dev/null.
Standard input, standard output and standard error are data streams. Known as stdin, stdout and stderr respectively.
[powerkit_alert type=”info” dismissible=”false” multiline=”false”]
A data stream is basically data that flows from a source and is put in a destination. For example, when you run a command that outputs something in the terminal, the source is the command and the destination is the terminal.
Another destination can also be a file, like when you write the output of a command to a file. (It’s useful to know these terms, to avoid confusion when reading documentation).
[/powerkit_alert]
When we run any command line application or utility, we run commands. These commands are usually in the form of the name of the utility most of the time followed by options and our variable input.
What happens after running, the command does what the utility function is written to do. For example, let’s run the which utility.
The which command is written to locate a program in the user’s path. When we run which ls, we are asking it to locate the ls utility in our path, giving us the location of this utility in our computer.
which ls
/usr/bin/ls
When we run which command correctly for ls, which finds the ls utility located at /usr/bin/ls
We can programmatically confirm that which ls successfully ran by displaying its exit status.
echo $?
0
An exit status is a number between 0 and 255 that is returned by a program to indicate success or failure. The most common exit status is 0, which indicates success. A non-zero exit status indicates an error.
We ran echo $? after which ls and we were given the exit status. Since the command ran successfully the exit status is 0.
When we run a command that will give us an error, such as whichh ls (we make a typo with an obvious typo of an additional h at the end and run which), we are provided with an error.
whichh ls
Command 'whichh' not found, did you mean:
command 'which' from deb debianutils (4.9.1)
Try: sudo apt install <deb name>
When we tried to run whichh ls, which resulted in an error, and the echo $? output is different.
echo $?
127
In Linux, these values that we are seeing after running the echo $? are called file descriptors. File descriptor 1 means stdout and file descriptor 2 means stderr.
When we ran the whichh (with a typo) we got file descriptor 1, 2, and 7 because value 127 is returned by the bash shell when the given command is not found within your PATH system variable and it is not a built-in shell command.
Redirecting stdout and stderr
Now that we understand that for every command there are outputs and errors, and that these outputs and errors are given a file descriptor, we can manipulate the data streams of stdout and stderr to our liking.
We do that by redirecting the output from being shown in the terminal to anywhere else.
We can send it to a text file for example.
ls > myfiles.txt
In this example we are listing the files in our directory with the ls command.
With the > (greater sign character), that looks like a sending arrow, we are taking the standard output of the ls utility and redirecting it to a file called myfiles.txt.
Instead of ls doing it’s normal function of listing the files in our directory and outputting the results to our terminal, this time we didn’t get any output.
That is because the stdout was redirected and written to a text file.
Following that, we did an echo $? to see the exit status of the previous command. We see that it was exited successfully.
echo $?
0
Then we performed a regular ls listing of the files in our directory and we can see there are four files.
ls
1.html 2.html 3.html myfiles.txt
Then we use the cat command to print the content of our text file myfiles.txt and we see an identical result as our ls listing.
cat myfiles.txt
1.html 2.html 3.html myfiles.txt
There we successfully redirected the output of stdout. This example is just a simple demonstration of what we can do with the redirection.
In this case just using a > (greater sign character) was enough for bash to process our command because if not specified, bash will use stdout as the default file descriptor to use.
Redirecting to /dev/null
Now we are advancing. We know that commands create outputs and errors. We know that these output and errors exit with a status and are given a file descriptor number. And we know that we can manipulate these outputs and errors via their file descriptor numbers.
Now let’s send them both, outputs and errors to /dev/null.
In this demo we first list files with the ls command and we see that there are 4 files in the directory.
ls &> /dev/null
1.html 2.html 3.thml myfiles.txt
And with echo $? we see that it was a successful exit with the file descriptor 0.
echo $?
0
Remember that a 0 file descriptor indicates that the previous command exited successfully, an unsuccessful one returns a non-zero value that usually can be interpreted as an error code.
Then we listed files again but the second time sending everything to /dev/null.
ls &> /dev/null
If we wanted to send a specific file descriptor output, we would use 1> for stdout and we would use 2> for stderr.
A &> sends both stdout and stderr file descriptors to /dev/null.
In our example, after listing files and sending everything to /dev/null, we ran echo $? to check the exit status and we see that indeed the operation was performed successfully but nothing was listed by ls because everything got sent to the blackhole that is /dev/null.
/dev/null 2>&1
Another way to send outputs to /dev/null is to use the >& operator. The >& operator takes the output of the first file descriptor and redirects it to the output of the second file descriptor.
In this format, it takes the stderr 2 and redirects it to stdout 1. Let’s take a look at another example.
Here again we are using the ls command, but we are using it with a -7 option which is an invalid option.
We attempt to use it and we receive an error.
ls -7
ls: invalid option -- '7' Tru 'ls --help' for more information.
With echo $? we check the exit status and verify that it indeed is an stderr output (2).
echo $?
2
We again attempt to list with the ls -7 invalid option and this time we send the output with > to /dev/null telling it to redirect the stderr output to stdout into /dev/null.
ls -7 > /dev/null 2>&1
Then we used echo $? again to check the exit status.
echo $?
2
While the effect is identical that it sends everything to /dev/null, using the >& operator has advantage when suppressing errors from coming into scripts.
It’s a technique commonly used to prevent automated scripts set to run on their own from running into unexpected exceptions.
It’s a good technique to use because it verifies if a command exists without errors and only runs said commands if there are no errors.
An important tool in the professional system administrator.
Conclusion
Using /dev/null is an important tool to use when operating the command line.
In a simplistic explanation the null device just writes to files with the specific instruction to discard everything right away after writing it. Thrown in a thrash bucket inside a blackhole never to be acknowledged or retrieved again. Out of the disk and out of the memory.
We learned how command line utilities go about operating. How they perform standard outputs and errors. How to identify these outputs. What to do with them to filter errors in or out with dev null. If you encounter any issues, have any questons or feedback, then feel free to leave a comment and we’ll get back to you as soon as we can.
