This question already has an answer here:

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.

marked as duplicate by muru bash Jul 27 '18 at 9:57

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 5
    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
  • muru has earned his stripes and although being on the losing end of his judgement from time to time I trust him with closing this question even if it's 3 years older as you say. I haven't read either question nor answers but I surmise his judgement it's based on the fact there are better answers on the other. Coincidentally I just implemented: ``bash -c "echo $IntBrightness | sudo tee $backlight" > /dev/null` tonight to suppress unwanted terminal output. You can flag this with a mod and asked that all the dupe candidate answers be merged into this Q&A. Seems like a lot of work though... – WinEunuuchs2Unix Sep 13 '18 at 1:26
  • 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 1:45

>/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.

  • 2
    And what does that & before 1 indicate in 2 >&1 – Nobody Jun 27 '17 at 23:46
  • 14
    @Nobody "& indicates that what follows is a file descriptor and not a filename." 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 2 '18 at 5: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: stackoverflow.com/questions/818255/… – Vivek Chavda Dec 3 '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 7 at 22:24

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
  • 9
    Nice explanation. I also think there is a shortcut for the above: &> /dev/null – Chip Castle Aug 1 '13 at 20:48
  • 2
    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 6:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.