What does &＞ do in bash?

原文链接：https://stackoverflow.com/questions/24793069/what-does-do-in-bash

Q：
I was looking at pre-commit hook and discovered the following line because I was wondering why I always got an empy file called 1 in my directory after doing a commit.

git status 2&>1 > /dev/null

I believe the intent was to write the following, and I corrected it.

git status 2>&1 > /dev/null

However, I was curious about what the following syntax does exactly, so I looked up the man page.

git status 2&>1

Here is the man page.

  Redirecting Standard Output and Standard Error
      This  construct allows both the standard output (file descriptor 1) and
      the standard error output (file descriptor 2) to be redirected  to  the
      file whose name is the expansion of word.

      There  are  two  formats  for  redirecting standard output and standard
      error:

             &>word
      and
             >&word

  Of the two forms, the first is preferred.  This is semantically equivalent to

     >word 2>&1

However, this man page implies that the two are equivalent, which does not seem to be the case.

Can someone clarify the man page and explain exactly what is happening with this syntax?

A:
The operators we are using here are:

• > Syntax: file_descriptoropt > file_name
• >& Syntax: file_descriptoropt >& file_descriptor
• &> Syntax: &> file_name

If the file descriptor is omitted, the default is 0 (stdin) for input, or 1 (stdout) for output. 2 means stderr.

So we have:

• >name means 1>name – redirect stdout to the file name
• &>name is like 1>name 2>name – redirect stdout and stderr to the file name (however name is only opened once; if you actually wrote 1>name 2>name it’d try to open name twice and perhaps malfunction).

So when you write git status 2&>1, it is therefore like git status 2 1>1 2>1 , i.e.

• the first 2 actually gets passed as an argument to git status.
• stdout is redirected to the file named 1 (not the file descriptor 1)
• stderr is redirected to the file named 1

This command should actually create a file called 1 with the contents being the result of git status 2 – i.e. the status of the file called 2 which is probably “Your branch is upto-date, nothing to commit, working directory clean”, presuming you do not actually track a file called 2.