I've been getting myself comfortable with I/O redirection. I've become aware of the &> shortcut for 2>&1. I believe it also works as >&. There may be a nuance to that of which I'm not aware.

When using this it has to be in the middle of a command line:

ls test.txt missing &> output.txt

However, when using the long-form, it has to be at the end of the command line:

ls test.txt missing > output.txt 2>&1

When attempting to place the shortcut at the end it results in an error:

ls test.txt missing > output.txt &>
-bash: syntax error near unexpected token `newline'

Why is this? What makes the shortcut different such that it has to be used inline rather that at the end of the line the same way the long-form method does?

  • In your first example &> is at the end: It has one parameter, the name of a file to redirect to. – ctrl-alt-delor Jul 19 '15 at 12:19
  • Don't use that &> stuff anyway - especially if you don't know how to use it. Shortcuts like that are ok interactively for experienced users who know what they do and why, but they'll only get in the way for anyone else. First learn how and why the standard redirections work before trying to make sense of nonsense syntax extensions. – mikeserv Jul 19 '15 at 12:46

&>word is:

semantically equivalent to

>word 2>&1

It's not the same as 2>&1 alone. Just as for redirecting output, the word (destination) part is required. 2>&1 is actually using a different operator, and it requires the destination word too (it's "1" here).

Redirections are applied in order, and it's permitted to redirect more than once. You could change your command into:

ls test.txt missing > output.txt &>tmp.txt

and provide a destination for &> to see the effect. That's what it thinks you're trying to write, and the error says it expected to see that second filename and didn't find it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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