What does “> /dev/null 2>&1″ mean? at Xaprb

What does “> /dev/null 2>&1″ mean?

I remember being confused for a very long time about the trailing garbage in commands I saw in Unix systems, especially while watching compilers do their work. Nobody I asked could tell me what the funny greater-thans, ampersands and numbers after the commands meant, and search engines never turned up anything but examples of it being used without explanation. In this article I’ll explain those weird commands.

Here’s an example command:

wibble > /dev/null 2>&1

Output redirection

The greater-thans (>) in commands like these redirect the program’s output somewhere. In this case, something is being redirected into /dev/null, and something is being redirected into &1.

Standard in, out, and error

There are three standard sources of input and output for a program. Standard input usually comes from the keyboard if it’s an interactive program, or from another program if it’s processing the other program’s output. The program usually prints to standard output, and sometimes prints to standard error. These three file descriptors (you can think of them as “data pipes”) are often called STDIN, STDOUT, and STDERR.

Sometimes they’re not named, they’re numbered! The built-in numberings for them are 0, 1, and 2, in that order. By default, if you don’t name or number one explicitly, you’re talking about STDOUT.

Given that context, you can see the command above is redirecting standard output into /dev/null, which is a place you can dump anything you don’t want (often called the bit-bucket), then redirecting standard error into standard output (you have to put an & in front of the destination when you do this).

The short explanation, therefore, is “all output from this command should be shoved into a black hole.” That’s one good way to make a program be really quiet!

Written by Xaprb

June 6th, 2006 at 9:26 pm

Posted in GNU/Linux

65 Responses to 'What does “> /dev/null 2>&1″ mean?'

Subscribe to comments with RSS or TrackBack to 'What does “> /dev/null 2>&1″ mean?'.

The short explanation, therefore, is “all output from this command should be shoved into a black hole.”

All the output, that is, except for error messages, right? So, one would use this structure to only listen to standard error?

Tim McCormack

6 Jun 06 at 11:29 pm
Error messages go to STDERR, which I’ve redirected to STDOUT, which is being shoved into a black hole. The program should not make a peep.

To listen only to STDERR, I can just redirect STDOUT into /dev/null, like so: wibble > /dev/null

Xaprb

7 Jun 06 at 8:26 am
My source for finding this information, since I usually forget how it works, is man bash and search for the REDIRECTION section.

Some of the man page is bash specific, but most is pretty generic.

Paul

10 Jul 06 at 2:44 pm
I’ve seen “2>&1 &” at the end of many tutorials, but I never knew what they were for. Thanks for the info guys.

chrisortiz

20 Jul 06 at 5:03 pm
Ah, I understand now — I misunderstood the nature of redirection, treating it as commands instead of pipes. That clears up a lot.

Tim McCormack

23 Jul 06 at 3:30 pm
So logically that means you could catch STDERR from the command line by appending “2>>/var/log/logfile” to a shell command.

So, where “2” is STDERR, “>>” is to append and “/var/log/logfile” is the where errors will be logged.

David

22 Nov 06 at 7:14 pm
Nice, Short, Sweet. So in short:

“> /dev/null” will redirect STDOUT to a BLACK HOLE

“2 > &1” will redirect STDERR to STDOUT which in turn is redirected to a BLACK HOLE

Right? Thank you for the explanation!

Tim

29 Nov 06 at 11:52 am
Yep, that’s right!

Xaprb

29 Nov 06 at 12:11 pm
Does it mean that

>/dev/null 2>&1

is equivalent to

>/dev/null 2>/dev/null?

Eric Dodemont

9 Jan 07 at 12:23 pm
Yes, that’s true.

Xaprb

9 Jan 07 at 1:04 pm
Excellent! Well explained.

Bobby Howie

12 Jan 07 at 10:58 am
Excellent Tutorial. Hats off Mr.Xaprb

Hari Ganesh

16 Jan 07 at 5:22 am
Hi,

This explanation helps clear a lot. Thanks and keep up the good work.

Raghu Balasubramanian

30 Jan 07 at 1:28 am
Good work friend :)

Nadeem

9 Feb 07 at 6:48 pm
Really excellent explanation, thanks!

Alex

21 Feb 07 at 7:40 am
So >/dev/null 2 > /var/log/logfile will redirect STDOUT to bit-bucket and STDERR to the log file. Am i right?

And if >/dev/null is given,will both STDOUT & STDERR be redirected to bit-bucket?

Hari Ganesh

8 Mar 07 at 12:56 am
Hari, your first sentence is right, but in the second, only STDOUT goes to the bit-bucket.

Xaprb

8 Mar 07 at 8:51 am
If &1,&2,&3 are used to refer to STDIN,STDOUT and STDERR respectively
Then why not “wibble > /dev/null &2>&1 “
instead of “wibble > /dev/null 2>&1″

Aman Jain

25 Mar 07 at 11:33 pm
just try: ” ;tryME >> /dev/null 2>&1 ” it outputs bash: syntax error near unexpected token `;’ :))

pulica

27 Mar 07 at 3:04 pm
to answer you Aman Jain I think that:
1) “wibble > /dev/null 2>1″ stdout is redirected to /dev/null and stderr is redirected to a file named “1″ (in the current directory)
2) “wibble > /dev/null 2>&1″ stdout is redirected to /dev/null and stderr is redirected to where stdout is redirected (bit bucket)
3) “wibble > /dev/null &2>1″ stdout is redirected to /dev/null , then character “&” comes, which means that this process will run in background(parallel with the shell u are using). Then comes 2>1 which will create an empt file with the name 1.
And FINALLY!!!
4) “wibble > /dev/null &2>&1 ” stdout is redirected to /dev/null. “&” means that, that process(wibble) will run in background(with stdout redirected only).Then another process is started with 2>&1 which creates no file.
U can try it. Maybe im wrong somewhere, Hey im not Steve Bourne(author of sh) ;)

pulica

27 Mar 07 at 3:28 pm
a good job

tnt

24 Apr 07 at 8:51 pm
Thanks a lot….Your information really helped me a lot.

Arun

10 May 07 at 2:10 am
Thanks to xaprb for the nice explanation..

ajay

31 May 07 at 5:00 am
Hi,

This is an awsome sweet tutorial. I have the following:
find . -mtime 3 -regex ‘.*\.md5$’ | xargs sudo rm -f {} \; > /dev/null 2>&1

I am trying to find files that are modified past 3 days or files more than 3 days old, remove them and redirect them to >dev/null…

When I redirect > TO /dev/null 2>&1 the entire command didn’t work, and when I removed things started working.

My question is

1. Do we need to specify the /dev/null 2>&1?
2. Is this for what went wrong - post analysis kind of thing?

Thank you

Raj

Raj

7 Jun 07 at 7:01 pm
Great little article - thankyou.

Cameron

10 Jul 07 at 6:48 am
good explanation..was wonderin all these days as to y we ve de > /dev/null 2>&1 in all our cronjobs…… thx… :)

iris

8 Aug 07 at 7:06 am
echo “good work man, thx a lot” >/dev/null 2>&1;
lol

bilel

25 Aug 07 at 4:37 am
In the following statement there is a “”. Does that combination signify someting unique or is it just a input and output redirection symbol sitting side by side?

smf: :sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2/dev/msglog “), then exactly what is this statement saying?

Mel Briggs

2 Sep 07 at 9:27 am
I just submitted a question and noticed that the main item I needed clarification on was stripped out. I wanted to know how the information flows within a signle command when there are multiple redirection symbols, and in this case, a input redirection symbol placed right next to an output redirection symbol. It looks like: “smf: :sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2/dev/msglog /dev”. That puts the less-than and greater-than signs adjacent. (From Solaris 10 etc/initab.)

Mel Briggs

2 Sep 07 at 9:34 am
Av been using >/dev/null 2>&1 for as long as i can remmeber with no clue but now it’s clear.Thanks for the tutorial

Oscar Rombo

3 Sep 07 at 2:29 am
Its a very useful info, if somebody doubted so, no easy to understand even if it looks simple, thanks god, now it apprears first in the googe search result.\

Thank you once again,.

Ram

18 Sep 07 at 2:51 pm
If anyone is wondering how to refer to the greater-than sign (or angle bracket) when used in this context - some people call it a “hoinky” Probably my all-time favorite tech jargon term

jt

19 Sep 07 at 4:04 pm
[...] What does … mean? at Xaprb – [...]

My del.icio.us bookmarks for September 27th-- Tales of a Minnesota Geek

27 Sep 07 at 8:47 pm
grt job

remo

8 Oct 07 at 1:41 pm
Would anyone be able to explain why it wouldn’t work if you wrote it like this?

command 2>&1 >> file

Luke

8 Nov 07 at 12:57 am
This was a very helpful tutorial. Thanks again!

Mike

28 Nov 07 at 11:58 am
Why do you need the & symbol in from of 1?

Mark

8 Dec 07 at 5:31 pm
If I recall correctly, “>&” redirects handles vs. “>” redirecting output to a file. If you leave out the & it would create a file named “1″

jt

8 Dec 07 at 6:10 pm
Really well done. Thanks for being so clear and concise!

MattS

3 Jan 08 at 6:43 pm
Great job, thanks a lot!

Janbur

9 Jan 08 at 10:06 am
Please explain difference between 2>&1 and 2&>1

Neeraj

16 Jan 08 at 12:49 am
2>&1: it means 2(stderr) is redirected to &1. & tells the address (fd) of 1(stdout). so the stderr is redirected to stdout.
2&>1: it means 2 that is nothing will get executed in bg because of &. And the output will be redirected to a file named 1 not the stdout.

VJ

15 Feb 08 at 1:56 pm
Excellent tutorial, I’m glad people like you exist :)

Steven

21 Feb 08 at 12:47 pm
Good job! I never understood this!

Martin

25 Feb 08 at 2:33 pm
i feel agitated when i have to use something without knowing what its meant for. your info was a quick insight. thanks a million

sas

3 Mar 08 at 5:02 pm
Great stuff,
I have a question. Specailly on bash, if I connect to a computer with ssh and run a process in background with ./job & and try to quit the shell hangs or actually waits for the process to finish, which is not what I want. I want to quit and let the process run.

Now I have a solution to this problem, i.e, if I put ./job 2

Xrules

24 Mar 08 at 3:58 pm
I was trucncated..

Now I have a solution to this problem, i.e, if I put “./job 2

Xrules

24 Mar 08 at 3:58 pm
truncated again because of less than symbol
Now I have a solution to this problem, i.e, if I put ./job 2 [lessthan symbol instead of greaterthan]/dev/null (note the direction is inward and not outward) the shell happily exits and leaves the process in background.

Any ideas why this happens would be educating.

Thanks in advance and the article and the discussion are helpful

Xrules

24 Mar 08 at 3:59 pm
Xrules, look into the nohup command. Even better, though: use screen. It is one of the top 5 things I cannot live without.

Xaprb

24 Mar 08 at 6:19 pm
Thanks

Arun

2 Apr 08 at 2:42 am
I used redirectors all the time, but the 2>&1 always confused me, very well explained!

adam

5 Apr 08 at 11:54 am
Here’s a shortcut for directing stdout and stderr to /dev/null:

wibble >& /dev/null

Now I have a question: What if I want to redirect stdout and stderr to a file called “2″? “wibble >& 2″ doesn’t do it, of course.

Ryan

7 Apr 08 at 1:33 am
>/dev/null 2>&1

is equivalent to

>/dev/null 2>/dev/null?

Then can we say like, “&” is used to trace the direction where 1 (STDOUT) directed?

Dinesh

7 Apr 08 at 4:26 am
Also, Is it possible to redirect only the STDERR error message to any log file (without redirecting program output to STDOUT)

Dinesh

7 Apr 08 at 4:36 am
Ryan:
wibble >./2 2>&1

Dinesh - see VJ’s comment above for your first question.
your second question is also answered in the original post and comments:
ls 2>stderr.log

jt

7 Apr 08 at 12:10 pm
Thanks Jt…

Dinesh

8 Apr 08 at 12:27 am
thanks it helped me a lot

bheemboy

16 Jun 08 at 12:03 pm
And if you just want to hide STDERR output (for instance if you’re creating a bunch of system vars), you can say 2>/dev/null.

export VAR=`command that causes lots of error output 2>/dev/null`

Michael

23 Jul 08 at 8:49 pm
To Eric Dodemont and Dinesh:

It is not exactly correct to say that the command

Command 1: wibble >/mylogs/logfile 2>&1

is equivalent to the command

Command 2: wibble >/mylogs/logfile 2>/mylogs/logfile

99.99% of the times you treat them identically, the result will be interchangeable, but if the wibble program generates both normal output on STDOUT and error messages on STDERR, you might notice a difference.

This gets really nit-picky, but here’s the explanation. Command 1 sets up a situation in which the process running wibble has a single I/O channel to /mylogs/logfile which is shared cooperatively by the STDOUT and STDERR pipes. However, command 2 sets up a different situation in which there are TWO independent I/O channels to /mylogs/logfile, one used by the STDOUT pipe, and the other by the STDERR pipe.

In the single channel situation, there’s a single location that keeps track of how the file is being written - specifically the position in the file for the next write. In the dual channel case, there are two separate and uncoordinated locations tracking the position of the next write.

The end result is that in the single channel case, the logfile receives output and error messages in the sequence in which they are generated by the wibble program, but in the dual channel case, error messages tend to overwrite normal output and vice-versa.

So, if the wibble program would normally run like this:

wibble
This is a line of output.
error 1

This command:

wibble >/mylogs/logfile 2>&1

will generate a logfile that looks like this:

This is a line of output.
error 1

Whereas this command:

wibble >/mylogs/logfile 2>/mylogs/logfile

generates a logfile that looks like this:

error 1 a line of output.

wjs32246

24 Jul 08 at 8:05 pm
To Luke:

the reason that this command:

Command 1: wibble >/mylogs/logfile 2>&1

works differently than this one:

Command 2: wibble 2>&1 >/mylogs/logfiles

has to do with the way in which the shell processes the command line. The shell deals with the I/O redirection tokens not as a totality, but rather in the sequence in which they appear; thus, in command 1, STDOUT is directed to logfile, then STDERR is directed to the same place as STDOUT, whereas in command 2, STDERR is directed to the terminal (because that’s where STDOUT is directed at this time), *then* STDOUT is redirected to logfile.

wjs32246

24 Jul 08 at 8:18 pm
Thanks. I didn’t think I was going to get an answer for that :)

Luke

25 Jul 08 at 3:09 am
“> /dev/null 2>&1″ mean?

action 1: STDOUT is redirected to /dev/null
action 2: STDERR is redirected to STDOUT

question 1: is the above action 1 & action 2 is happening serial or parallel?

question 2: if the above actions happens in serial in which order do they happen? (action 1 -> action2) /or/ (action 2 -> action 1)

if the above questions are invalid then it means still I didn’t understand it. TIA.

smg

22 Aug 08 at 1:57 pm
simple and explain. I cannot leave this page without typing this comment. Thankyou.

vadivu

7 Sep 08 at 10:42 pm
I’ve been trying to keep a cron job from writing to the mail spooler for output and errors. Using the >/dev/null 2>&1 would work, but it suppresses all the file output, and these jobs write to a file for status reporting. Is there anything I can do to have the normal onscreen output written to dev/null but keep the other file outputs?

Bill

12 Sep 08 at 8:42 am
Thanks a lot…
its really clear my doubt…

Jyoti Mishra

24 Sep 08 at 7:36 am

Xaprb