/dev/null is a character device, major 1, minor 3. It is not a file on a disk, it has no size, and it stores nothing. Two rules define it completely:

writes succeed and vanish. Anything written to it is accepted and immediately discarded. The write returns success, so the program writing never knows the difference.
reads return end-of-file at once. Reading from it gives you nothing, immediately — zero bytes, no waiting, no error.

That pair — accept everything, return nothing — is the whole device. It has worked this way since the earliest Unix, and it has never changed, because there is nothing to change.

Nearly every program writes output, and not all of it is wanted. Without a sink, your choices are reading output you will ignore, or rewriting the program to shut up. /dev/null is the third option: a place to send output that is guaranteed to accept it and guaranteed to do nothing with it.

The key property is that writing to it succeeds. A program that writes to /dev/null does not fail, does not block, and does not fill a disk. Its exit status is unaffected. That is what makes it safe to use blindly — and what makes it different from closing output or pointing it at a full disk.

discard standard output, keep errors: command >/dev/null — you want to know if it failed, not what it did.
discard errors, keep output: command 2>/dev/null — the classic for noisy commands (find through directories you cannot read, for example).
discard everything: command >/dev/null 2>&1 — silence, total. The order matters: stderr is pointed at wherever stdout currently goes, so the >/dev/null must come first.
cron jobs: a chatty cron job mails you its output every run; redirecting to /dev/null is how you stop the mail without touching the job.
measure without the body: curl -s -o /dev/null -w "%{http_code}" https://example.com — the response body goes to the void, the status code comes back to you.

The original 2017 stub carried one command and a dire warning:

mv / /dev/null

The truth is less dramatic: it fails. mv cannot move a directory onto something that is not a directory, and /dev/null is a character device. The command errors out and does nothing at all — which is the one thing /dev/null guarantees.

The warning underneath it, though, was sound: do not paste commands you do not understand, especially ones strangers hand you. The genuinely destructive commands are not this one — they are the ones that do exactly what they say, like wiping a filesystem or writing to the wrong disk, and they do not ask twice. If you cannot explain what a command does, it does not run on a live system. Test VMs exist for exactly this reason.

/dev/zero: reads return an endless stream of zero bytes. Useful for creating empty files and wiping disks (dd if=/dev/zero of=/dev/sdX — on the right disk, on purpose).
/dev/full: the opposite of /dev/null — every write fails with “No space left on device.” It exists so you can test how your program behaves when the disk fills up, without filling up a disk.
/dev/null sits between them: zero gives you everything, full gives you an error, null gives you silence. Three devices, three answers to “what happens to my output?”

Somebody, someday, removes /dev/null — usually a script that got enthusiastic, occasionally a person testing the previous section. Symptoms are immediate and confusing: programs fail with “No such file or directory” in places that used to work.

Recreate it (as root): mknod /dev/null c 1 3 && chmod 666 /dev/null — character device, major 1, minor 3, readable and writable by everyone, exactly as it was. On most modern systems udev recreates it at boot anyway, so a reboot also fixes it — but the mknod is faster than explaining the outage.

Silence output: >/dev/null for stdout, 2>/dev/null for stderr, >/dev/null 2>&1 for both — order matters.
The joke command: mv / /dev/null fails harmlessly; the danger is pasting commands you cannot explain.
Recreate it: mknod /dev/null c 1 3 && chmod 666 /dev/null. Verified against current Linux device behavior, Oct 26, 2026.