What does &> do in bash?

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 equiva‐
      lent 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?

The operators we are using here are:

• > Syntax: file_descriptor_opt > file_name
• >& Syntax: file_descriptor_opt >& 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.

&>word (and >&word redirects both stdout and stderr to the result of the expansion of word. In the cases above that is the file 1.

2>&1 redirects stderr (fd 2) to the current value of stdout (fd 1). (Doing this before redirecting stdout later in the line does not do what you might expect and will split the outputs instead of keeping them combined and is a very common shell scripting error. Contrast this to >word 2>&1 which combines the two fds into one sending to the same location.)

$ { echo stdout; echo stderr >&2; }
stdout
stderr
$ { echo stdout; echo stderr >&2; } >/dev/null
stderr
$ { echo stdout; echo stderr >&2; } >/dev/null 2>&1
$ 
{ echo stdout; echo stderr >&2; } 2>&1 >/dev/null
stderr

Not that those are, while similar looking, not the same thing.

git status 2&>1 > /dev/null is, in fact, actually running git status 2 with a redirection of &>1 (stdout and stderr to file 1). Almost certainly not what was intended. Your correction almost certainly is what was intended.

$ git init repro
Initialized empty Git repository in /tmp/repro/.git/
$ cd repro/
$ git status
# On branch master
#
# Initial commit
#
nothing to commit
$ ls
$ git status 2>&1
# On branch master
#
# Initial commit
#
nothing to commit
$ ls
$ git status 2&>1
$ ls
1
$ cat 1
# On branch master
#
# Initial commit
#
nothing to commit