166

Oftentimes I run into small bash scripts that use this sort of syntax in if statements:

some command > /dev/null 2>&1

What is the purpose of outputting to /dev/null like that, and what does the 2>&1 mean?

It always seems to work but I'd like to know what it's doing.

Eliah Kagan
  • 117,780
javanix
  • 1,793
  • 18
    Not sure why this question was marked as a dupe, it was clearly open for 3 years before the other one was even posted. – javanix Aug 28 '18 at 14:33
  • I just noticed you were the OP and not a passer by. I've reviewed both Q&As and am voting to reopen your question. I think yours is more general and suits my needs tonight (getting rid of 650 or 3000 echoed to screen based on nighttime or daytime brightness levels. Whereas the other question is strictly about error messages (File Descriptor 2>/dev/null), One notorious example is Gtk transient parent in Zenity and Yad which use Dialog Windows instead of full windows. My initial comment was too hasty... PS w/formatting: bash -c "echo $IntBrightness | sudo tee $backlight" > /dev/null – WinEunuuchs2Unix Sep 13 '18 at 01:45

2 Answers2

209

>/dev/null redirects the command standard output to the null device, which is a special device which discards the information written to it

2>&1 redirects the standard error stream to the standard output stream (stderr = 2, stdout = 1). Note that this takes the standard error stream and points it to same location as standard output at that moment. This is the reason for the order >/some/where 2>&1 because one needs to first point stdout to somewhere and then point stderr to the same location if one wants to combine both streams in the end.

In practice it prevents any output from the command (both stdout and stderr) from being displayed. It's used when you don't care about the command output.

Mikko Rantalainen
  • 3,360
João Pinto
  • 17,159
  • 5
    And what does that & before 1 indicate in 2 >&1 – Nobody Jun 27 '17 at 23:46
  • 23
    @Nobody "& indicates that what follows is a file descriptor and not a filename." https://stackoverflow.com/a/818284/5948237 – Vivek Chavda Sep 19 '17 at 18:41
  • @VivekChavda How come the 2 (stderr) doesn't need that distinction? – deanresin Dec 02 '18 at 05:54
  • I was just copying from the answer I linked, I'm not familiar with all this myself. Here's a comment from under that answer: https://stackoverflow.com/questions/818255/in-the-shell-what-does-21-mean/818284#comment32269807_818284 – Vivek Chavda Dec 03 '18 at 21:07
  • Those last 2 sentences ("In practice it prevents any output from the command (both stdout and stderr) from being displayed. It's used when you don't care about the command output.") should be bold. That's a pretty important piece of information just hanging out there at the end. I'd like it to stick out more. – Gabriel Staples Feb 07 '19 at 22:24
  • Hey thanks for the answer. While I upvoted it, why do we have to provide the & for stdout and not simply say 2>1 instead of 2>&1 – Ayusman Mar 15 '19 at 04:57
77

STDIN is represented by 0, STDOUT by 1, and STDERR by 2.

/dev/null is the bit-bucket: the place where you dump anything you don't need.

So, the STDOUT is redirected to the bit-bucket(trash) and the STDERR is redirected to where the STDOUT is located: the bit-bucket.

You can also do this:

>/dev/null 2>/dev/null
Sid
  • 10,533
  • 11
    Nice explanation. I also think there is a shortcut for the above: 
    &> /dev/null
    – Chip Castle Aug 01 '13 at 20:48
  • 4
    The shortcuts &> and >& are a bit frowned upon because those are "bashism" - they do work with bash shell but are not compatible with some other POSIX compatible shells. The >... 2>&1 ... syntax works in every POSIX compatible shell. – Mikko Rantalainen Sep 11 '18 at 06:05