Sending data into the void with /dev/null

leap into the void macinate
Credit: flickr / macinate

Unix systems make it easy to make output that you don't want to see simply disappear. Toss output into the void. Send errors in one direction, useful output in another. Something of a bit bucket, black hole, and digital garbage disposal, /dev/null is one of the very clever things that Unix introduced into the computing world. And what a very clever and unusual one!

Nearly everyone who spends time on the Unix command line has probably heard of /dev/null and a good many of us probably use it routinely -- especially those of us who write scripts. But how much have you thought about the file's many peculiarities? Let's take a deep dive into our systems' implementation of anti-matter and see how very unusual a thing it really is.

First, the creation date of /dev/null is the date/time that your system last booted. Interestingly, this intriguing file is created anew every time you reboot your system. That's probably a very good thing as /dev/null is a file that you wouldn't ever want to lose. Here it is on one of the systems I manage:

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Dec 12 20:00 /dev/null

Examining this long listing, you can see that /dev/null is a character device. This tells you that it processes data character by character rather than block by block. Notice also that it doesn't require execute permission to behave as it does. It's a pseudo device, not an executable.

If you use the stat command to look at the file's metadata, you'll note that its size is reported to be 0. Yes, non-executable and empty, /dev/null still manages to do some very interesting things for its users.

$ stat /dev/null
  File: `/dev/null'
  Size: 0               Blocks: 0          IO Block: 4096   character special file
Device: 11h/17d Inode: 3720        Links: 1     Device type: 1,3
Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-12-12 20:00:19.359656104 -0500
Modify: 2015-12-12 20:00:19.359656104 -0500
Change: 2015-12-12 20:00:19.507656104 -0500

The file's read and write for everyone permissions make sense only when you think about how /dev/null is used. You write to /dev/null every time you use it in a command such as touch file 2> /dev/null. You read from /dev/null every time you empty an existing file using a command such as cat /dev/null > bigfile or just > bigfile. Because of the file's nature, you can't change it in any way; you can only use it. And, if you can remove it, a reboot puts it back. How nice.

Fortunately, you can tell if an operation is successful even if your output simply disappears -- and this is key to using /dev/null in a script. For example, in the script excerpt below, we touch a file and then check to see if the file was updated or created by examining the return code -- the code that tells us whether the command just processed was successfully completed. If the operation failed, the return code will be 1 or greater. If it succeeded, the return code will always be 0.

You can check return codes on the command line with simple checks like this:

$ echo hello > /dev/null
$ echo $?
0

In a script, you're likely to do something like this:

touch $file 2> /dev/null
if [ $? != 0 ]; then
    echo File creation failed
    exit 1
else

The use of /dev/null in the code above ensures that the person running the script sees a gentle error "creation failed" message rather than a "Permission denied" error. The benefit of crafted messages increases dramatically with the volume of data might otherwise be filling your screen.

tar xf /var/tmp/app.tar 2> /dev/null

In the tar command shown above, we extract from a tar file, but hide possible errors from view. This is the kind of thing that many sysadmins will do in a script to reduce the output that their scripts will generate. Checking the return code will let you know if there were errors.

This kind of command probably won't make a lot of sense to use except when all you want to know if whether a command that you ran completed successfully, not what kind of output it might have produced. That's an easy thing to do and quite commonly done in scripts. Just run the command and then make use of the return code to determine whether the command ran successfully.

#!/bin/bash

cd /usr/local/apps
tar xf /var/tmp/app.tar 2 >/dev/null
if [ $? != 0 ]; then
    echo extract failed
    exit 1
fi

So, /dev/null acts like a file and looks like a file (and maybe even smells like a file), but it's really a data sinkhole implemented as a file.

The most common use of /dev/null is to get rid of standard out, standard error, or both. Selecting which data source you want to squelch is easy. Get rid of standard output with commands like echo hello > /dev/null or echo hello 1> /dev/null. Get rid of errors with commands like touch file 2> /dev/null.

The second common use is to empty files that you don't want to remove, but you want to lose their content. This can be very important if a running process needs to write to that file and will lose its connection to it if you remove the file and recreate it (remember that running processes connect to files using file handles).

$ ls -l bigfile.log
-rw-r--r-- 1 oracle oinstall 10485769265 Nov 10  2013 bigfile.log
$ cat /dev/null > bigfile.log
$ ls -l bigfile.log
-rw-r--r-- 1 oracle oinstall           0 Jan 21 09:51 bigfile.log

You can't pipe data to /dev/null because the receiving end of a pipe has to be an executable that will be able to process the received data.

$ echo hello | /dev/null
-bash2: /dev/null: Permission denied

Unix sysadmins often use /dev/null in cron jobs so that cron never sends them email. If they want to receive email from those scripts, they'll generally code those messages in the scripts themselves and send them using a command like mailx.

*/30 * * * * /usr/local/bin/chkSamba > /dev/null

I was surprised a couple years ago to discover that Windows has a /dev/null type feature. In a command prompt, you can run commands like echo haha > NUL and you'll get the same effect as you would redirecting data to /dev/null on a Unix system.

Also referred to as the "bit bucket," /dev/null might be one of the most novel ideas that went into Unix. It has been around since the beginning of the OS and provides some wonderfully handy options for dealing with data that you don't want to see or retain.

You can think of /dev/null as being something like anti-matter or "the void". While /dev/null is itself just a file that you'll find on every Unix system, its use is entirely different than any other file you'll run into.

General forms for /dev/null use

Send standard out to /dev/null:

command > /dev/null

Send standard error to /dev/null:

command 2> /dev/null

Send both standard out and standard error to /dev/null:

command > /dev/null 2>&1

Extremely useful and innovative, /dev/null has been one of the things about Unix that has made my work so much easier all these years. And, even after so many decades, it still retains a certain mystique.

This article is published as part of the IDG Contributor Network. Want to Join?

A look inside the Microsoft Local Administrator Password Solution
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies