What does >& mean?

This is the same as &>. From the bash manpage:

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

• 10
  I feel foolish. I spent a bunch of time reading other sources and it was right there in the manpage.

  – contrapositive

  Jun 29, 2012 at 3:32
• 3
  >& is the syntax used by csh and tcsh to redirect both stdout and stderr. That's probably why bash accepts it.

  – Keith Thompson

  Jun 29, 2012 at 5:46
• 4
  Does this mean that &>word and >word 2>&1 are semantically equivalent? The antecedent to "This" is not clear to me.

  – geneorama

  Mar 11, 2015 at 16:04
• 9
  @geneorama &>word, >word 2>&1, and >&word are exactly the same.

  – jordanm

  Mar 11, 2015 at 17:28
• 1
  Now I realize that I made a mistake before based on what I read elsewhere. > only redirects standard out. > does not redirect error. (I should probably redirect my future comments to /dev/null)

  – geneorama

  Mar 11, 2015 at 17:53

&> vs >&: the preferred version is &> (clobber)

Regarding:

• &>
• >&

both will clobber the file - truncate the file to 0 bytes before writing to it, just like > file would do in the STDIN-only case.

However, the bash manual Redirections section adds that:

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

>word 2>&1

When using the second form, word may not expand to a number or -. If it does, other redirection operators apply (see Duplicating File Descriptors below) for compatibility reasons.

(Note: in zsh both are equivalent.)

It's very good practice to train your fingers to use the first (&>) form, because:

Use &>> as >>& is not supported by bash (append)

There's only one append form:

The format for appending standard output and standard error is:

&>>word

This is semantically equivalent to

>>word 2>&1

(see Duplicating File Descriptors below).

Note:

• The clobber usage of &> over >& in the section above is again recommended given that there is only one way for appending in bash.
• zsh allows both &>> and >>& forms.

• so is & a special character that gets converted to 1 and 2 by the shell interpreter?

  – Fakher Mokadem

  Oct 13, 2019 at 11:06
• @FakherMokadem Nope, see the manual.

  – Tom Hale

  Oct 14, 2019 at 9:15

Slightly off-topic, but this is why I stick to the long form like >/dev/null 2>&1 all the time. That is confusing enough for people who do it backwards in things like cron without adding >&, &>, >>&, &>>, ... on top of it. I frequently need to add notes in crontab -l reminding people that "2>&1 > /dev/null" is not a best practice.

As long as you remember that any "final destination" is given first, then it should be the same syntax on any Unix or Unix-like system using any Bourne-like shell, appending or otherwise. Plus, since &> is effectively a Bash-ism (may have originated in csh? don't recall, but it is not POSIX either way), it is not always supported on locked-down commercial UNIX systems.

Now I realize that I made a mistake before based on what I read elsewhere. > only redirects standard out. > does not redirect error. (I should probably redirect my future comments to /dev/null)