What does >& mean?


What does >& mean?



I was a little confused by this expression:


gcc -c -g program.c >& compiler.txt



I know &>filename will redirect both stdout and stderr to file filename. But in this case the ampersand is after the greater than sign. It looks like its of the form M>&N, where M and N are file descriptors.


&>filename


filename


M>&N


M


N



In the snippet above, does M=1 and N='compiler.txt'? How exactly is this different from:


M=1


N='compiler.txt'


gcc -c -g program.c > compiler.txt (ampersand removed)



My understanding is that each open file is associated with a file descriptor greater than 2. Is this correct?



If so, is a file name interchangeable with its file descriptor as the target of redirection?




2 Answers
2



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





I feel foolish. I spent a bunch of time reading other sources and it was right there in the manpage.
– contrapositive
Jun 29 '12 at 3:32





It goes on to say "Of the two forms, the first is preferred. This is semantically equivalent to >word 2>&1"
– Dennis Williamson
Jun 29 '12 at 3:48


>word 2>&1





>& 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 '12 at 5:46


>&





Does this mean that &>word and >word 2>&1 are semantically equivalent? The antecedent to "This" is not clear to me.
– geneorama
Mar 11 '15 at 16:04


&>word


>word 2>&1





@geneorama &>word, >word 2>&1, and >&word are exactly the same.
– jordanm
Mar 11 '15 at 17:28


&>word


>word 2>&1


>&word


&>


>&


&>



Regarding:


&>


>&



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


> file



However, the bash manual Redirections section adds that:


bash



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.)


zsh



It's very good practice to get finger memory in the first (&>) form, because:


&>


&>>


>>&


bash



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:


&>


>&


bash


zsh


&>>


&>>






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

.

How to generate build files in next js

Delphi Android file open failure with API 26