Decoding `command > /dev/null 2>&1`
In this article we’ll learn about a famous redirection to /dev/null
with 2>&1
!

Most probably I first heard a formal computing use of directory
and folder
in grade 8 while talking about a computer filesystem. I had taken Computer Science instead of Economics for an optional subject, copying my close group of friends in the class. My CS teacher gave an example of cabinet and physical folder as an everyday example of how computer organize itself. Again came across them in undergrad. This time it was more complex with tree like structure where the root was a slash /
and it having it’s progeny.

Personal background aside, let’s get a short background on UNIX philosophy. It treats everything as a file. Want to write to a device? Treat it as a file. Want to write to a socket and send data over a network? Treat it as a file. Want to read a video? Treat it as a file. Hence, indicating a file to access it is crucial. It is known as file descriptor which is a non-negative integer, generally represented in the C programming language as type int
. Now let’s dive into the topic! 🌸
In BASH
programming, you must have seen this redirection.
command > /dev/null 2>&1
Here, /dev/null
path is for discarding your program’s output. Here null
is a special file called null device in UNIX systems. It discards all data that is written to it. It however reports that write operation to it succeeded. Jargon term for the path is called black hole. Let’s illustrate this with an example.
# write to /dev/null
$ echo 'hello world' > /dev/null# check status of the command
$ echo $?
0
In the example we used >
redirection symbol to write to /dev/null
path. The symbol $?
gives exit status of last executed command. 0
means success and non-zero (1–255) return means failure.
The $?
symbol is a combination of two distinct parameters.
?
: one special variable
$?
: gives value stored in variable ?
Let’s have an example that gives non-zero exit status:
$ ls -z
ls: illegal option -- z
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]$ echo $?
1
Here we get error message of illegal option -- z
, and the exit status is 1.
In Input/Output (I/O) Redirection, there are three default files open:
In the above example error is displayed into stderr
file. If you do not want to display it, you can redirect to stdout
. Let’s see this with an example:
$ ls -z > /dev/null 2>&1
$ echo $?
1
See, we do not see error message and command exit status is still 1
. Let’s dissect the command ls -z > /dev/null 2>&1
.
With 2>&1
, we are redirecting standard error output (file descriptor of 2
) to standard output (file descriptor of 1
) which gets written to /dev/null
. The >&
symbol is redirecting standard error output to standard output. The symbol &
in 2>&1
implies that 1
is a destination file descriptor.
Let’s see that that standard error output is actually redirected to standard output.
$ ls -z > /tmp/output_test 2>&1
$ echo $?
1
$ cat /tmp/output_test
ls: illegal option -- z
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
As intended, $?
exit status gives 1
and we see error has been redirected to /tmp/output_test
. Clearer? 🤔
There might still be an unsettling question of why 2>&1
is in the end of redirection? Why not put before redirecting to /tmp/output_test
? Reads at least logical. Good question.
This is because file descriptor is not a placeholder for the file. They are the input and/or output channel to the file. See everything in UNIX OS is treated as a file. So when you do > /tmp/output_test
, you are saying “open a write channel and leave it open”. This makes suppressing display of standard error output possible and it get’s redirected to standard output.
Let’s check it by changing position of 2>&1
(better you try on your own and check):
$ ls -z 2>&1 > /tmp/output_test
ls: illegal option -- z
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
$ echo $?
1
$ cat /tmp/output_test
See, the standard error gets displayed and nothing is there in /tmp/output_test
.
Congratulation on the completion! You are on your way to write intricate BASH scripts. 🍧
My next article most probably will be on middleware then maybe on different networking devices. If something more interesting and urgent appears, that might take a precedence. See you next week.
Thank you for reading.
Reference: