Why Is It Called /dev/null? The Black Hole of Unix

Every Unix system has a file that destroys whatever you write to it. You can send it gigabytes and it never fills up. You can read from it and get nothing back. It's been on basically every Unix-like machine since the 1970s, and it's probably the most-typed path in shell history after your home directory.

It's /dev/null, and the name is more literal than it looks.

The name, piece by piece

/dev is the directory where Unix keeps device files — the special files that represent hardware and kernel features instead of data on a disk. Your disks, your terminal, and your random number generator all live there. (If that sounds strange, it's the core idea from Everything Is a File.)

null means what it means in math and programming: nothing, empty, zero. A null device is a device that is nothing — there's no hardware behind it, and nothing stored inside it.

So /dev/null is just "the nothing device." The name describes exactly what it is.

Unix didn't invent the idea. Older systems had null devices too — IBM mainframe job scripts had DD DUMMY for "pretend this is a file, but throw everything away," and DOS and Windows still have NUL (as in dir > NUL). Unix's version stuck in the culture because it got a real path you can see, type, and joke about.

How it actually behaves

The rules are simple:

• Writing to /dev/null always succeeds. The data is thrown away immediately.
• Reading from /dev/null returns end-of-file right away. There's never anything to read.

You can confirm it's a real device file:

$ ls -l /dev/null
crw-rw-rw- 1 root root 1, 3 Oct 21 09:14 /dev/null

The c at the start means it's a character device. The 1, 3 are its device numbers — on Linux, that's how the kernel knows this file means "the null driver" and not your hard drive. And rw-rw-rw- means everyone can read and write it, which is the point: any program, run by any user, needs somewhere to throw things away.

What people use it for

Silencing output. The classic. Combined with file descriptor redirection, you can drop exactly what you don't want:

find / -name "*.conf" 2>/dev/null    # hide "Permission denied" spam
noisy-command > /dev/null            # hide normal output, keep errors
noisy-command > /dev/null 2>&1       # hide everything

Giving a program empty input. Some commands wait for keyboard input when you don't expect them to. Pointing stdin at /dev/null means they immediately see "end of input" instead of hanging:

some-script < /dev/null

Emptying a file without deleting it. Useful for log files a running process still has open:

cat /dev/null > app.log

(: > app.log or truncate -s 0 app.log do the same thing.)

Turning things off with a symlink. Point something that's supposed to be a file at /dev/null and it effectively disappears:

ln -sf /dev/null ~/.bash_history     # history gets written into the void

systemd uses this exact trick: systemctl mask disables a service by symlinking its unit file to /dev/null.

Standing in for "no file." Git uses /dev/null in diffs to mean "this file didn't exist." Every newly added file in a diff shows up as --- /dev/null, because comparing against nothing is the same as comparing against an empty file. You can use that yourself:

git diff --no-index /dev/null newfile.txt    # show the whole file as "added"

The family

/dev/null has siblings, and they're just as literal:

• /dev/zero — reading returns an endless stream of zero bytes. Handy for creating blank files: head -c 1M /dev/zero > blank.bin.
• /dev/full — on Linux, writing to it always fails with "No space left on device." It exists so you can test how programs behave when the disk is full.
• /dev/random and /dev/urandom — reading returns random bytes.

Same interface as any other file. Wildly different behavior behind it.

The culture

/dev/null escaped the terminal a long time ago. The old hacker dictionary, the Jargon File, lists it as slang for "the bit bucket" — anywhere information goes to die. "Send your complaints to /dev/null" is a decades-old way of saying "nobody's reading those." If someone tells you your email went to /dev/null, they're not being technical.

Where it can go wrong

• It's only a file, so it can be broken. If someone accidentally deletes /dev/null as root, the next program that writes to it creates a regular file at that path — which then quietly fills up with everything that was supposed to vanish. The fix is to recreate the device (mknod -m 666 /dev/null c 1 3 on Linux), and modern systems rebuild /dev on every boot anyway. Still, it's a fun one to diagnose.
• The program still does the work. Sending output to /dev/null hides it; it doesn't skip it. A command that spends ten minutes generating output still spends ten minutes.
• Hiding errors hides errors. 2>/dev/null is great for known noise and dangerous everywhere else. A script that silences all errors will also silence the one telling you the backup failed.
• It's not secure deletion. Copying a file to /dev/null doesn't erase the original. It just reads it.

Why it's worth knowing

/dev/null looks like a joke, but it's a small piece of really good design. Instead of every program needing a "quiet mode," an "ignore input" mode, and a "pretend there's no file" mode, Unix gives you one device that means "nothing" — and because it's a file, every tool already knows how to use it.

That's the pattern behind so much of Unix: don't add a feature to every program. Add one thing that every program can already talk to.