Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I know what

  program > /dev/null 2>&1 

does. It redirects the output to /dev/null and 2>&1 means to redirect the error output in the same place where the output is sent.

My problem is I always have to google it because I never remember it.

So, I try &2>1, 1>2&, 1>&2... I try every combination until I google it...

What's the trick to remember it easily?

share|improve this question

In regards to the bash shell I find the best way to remember is by understanding what is happening.
If all you want to do is remember how to get the command correct, you might try

program > /results 2> /results

That's nice and obvious whats going on and easy to remember. i.e.

  • 1 STDOUT is going to /results
  • 2 STDERR is also going directly to /results

the problem is this doesn't work as you would expect. consider the following:

file: /tmp/poem.txt

the quick brown fox jumped over the lazy dog

and the run the command

grep "brown" /tmp/poem.txt NOT_A_FILE > /tmp/results 2> /tmp/results

then

$ cat /tmp/results
grep: NOT_A_FILE: No such file or directory
 lazy dog

what happened here?
My understanding is bash setup the redirection pointing the STDERR directly to the file /tmp/results and because of the nature of > which does 2 things

  1. normally create a new file - in this case the opportunity has passed as bash has moved past this routine at the time the output is generated.
  2. insert straight into the beginning of the file. and not append like >> does.

So in this case STDERR, inserts directly into the beginning of /tmp/results overriding the output of STDOUT.
Note: if you used >> to append you could probably get away with this syntax.
However to fix the problem you need - not to redirect STDERR - to the file directly, but rather to merge STDERR's output into the STDOUT stream, so you don't get a collision.
Using the operator 2>&1 operator achieves this

grep "brown" poem.txt NOT_A_FILE > /tmp/results 2>&1

The & enables bash to distinguish from a file named 1 and the 1 file descriptor.
To me the statement 2>&1 itself explains exactly what is happening - STDERR is being redirected at STDOUT itself - and only ends up in /tmp/results because thats where STDOUT is pointed (almost as a side effect).
As opposed to what alot of guides claim, which is that 2>&1 sends STDERR to where ever STDOUT is pointed. If that were true - you would still have the overwriting problem.

For more information see - http://mywiki.wooledge.org/BashGuide/InputAndOutput#File_Redirection

share|improve this answer

Let us consider these three options:

program  2>1
program  2>1& 
program  2>&1

The first sends stderr to a file names "1": after all, bash expects to redirect to a file.

The second also redirects to the same file but runs program in the background: that is what a trailing & is supposed to mean.

That leaves the third possibility as the only one that makes sense in the bash universe for redirecting to a file handle.

How to remember which is which among 0, 1, 2? Think about running a computer from the console. First, you have to type something (0=stdin). Then, you see output (1=stdout). Lastly and only if something goes wrong do you see stderr (2).

share|improve this answer

Draw it in your wallpaper.

Now, seriously, this and other basic stuff I kept forgetting, so I added a quick tips menu to an app I developed and that I use daily. You might want to give it a try or use something like gnote to keep a note.

share|improve this answer

One trick is just to remember that 1 = standard output, 2 = standard error. So:

2>&1 = standard error stream goes into standard output stream.
1>&2 = vice versa.

If you have ever programmed in a C-like language, it's easy to remember the ampersand (&). I choose to think of it as referring to the "address of" existing file descriptor, so that you don't change the file itself or create a new one.

share|improve this answer

Seeing the & as a knot might help : think about what you want to do as taking the output of 2, so 2>, and tying it together with 1, so 2>&1

share|improve this answer
1  
I just memorized the phrase "two out and one". Whether your mnemonic is a phrase or a knot, having one will really help. – Tim Kennedy Oct 8 '11 at 15:56

Actually, it depends on what shell you're using. Bash is usually very forgiving and you can just do:

program &> file
share|improve this answer

Output is better than error so it comes first (1 vs 2).

> is shorthand for 'goes to'. On the left is what I want to send and on the right is where I want to send it. Since 'where' is (almost) always a file, something like

program > /dev/null 2>1

would redirect to a file named 1. Thus, the ampersand modifies the file to file descriptor.

Unfortunately, I haven't come across nor developed my own mnemonic, but when I was first learning *nix, I found this logical way to work well. After a few run-throughs, it becomes second nature.

share|improve this answer
    
Your first sentence doesn't make sense to me. stdout is file descriptor 1, stderr is 2. So, "error" comes before "output". – Warren Young Aug 19 '10 at 13:15
    
That sentence is a mnemonic to remember which file descriptor stdout and stderr refer. – gvkv Aug 19 '10 at 13:53
    
Okay, but it still seems confusing, since the original question is about trying to remember the order of the characters in the "2>&1" incantation. – Warren Young Aug 19 '10 at 13:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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