O que significa e exatamente no redirecionamento de saída?

Vejo coisas como command 1> outou com 2>&1para redirecionar o stderr, mas às vezes também vejo &>por si só, etc.

Qual é a melhor maneira de entender &e o que significa exatamente?

O &in 2>&1simplesmente diz que o número 1é um descritor de arquivo e não um nome de arquivo. Nesse caso, o standard output file descriptor.

Se você usar 2>1, isso redirecionará os erros para um arquivo chamado, 1mas se você o usar 2>&1, será enviado para o arquivo standard output stream.

Isto &>diz enviar ambos standard outpute standard error, em algum lugar. Por exemplo ls <non-existent_file> &> out.file,. Deixe-me ilustrar isso com um exemplo.

Configuração:

1. Crie um arquivo kokocom o seguinte conteúdo:

   #!bin/bash
   
   ls j1
   echo "koko2"
   

2. Torne executável: chmod u+x koko

3. Agora observe que j1não existe

4. Agora corra ./koko &> output

5. corra cat outpute você verá

   ls: cannot access 'j1': No such file or directory
   koko2
   

Ambos, standard error( ls: cannot access 'j1': No such file or directory) e standard output( koko2), foram enviados para o arquivo output.

Agora execute-o novamente, mas desta vez:

./koko > output

Faça cat outpute você só verá o koko2mesmo. Mas não a saída de erro do ls j1comando. Isso será enviado para o standard errorque você verá em seu terminal.

Nota importante graças ao @Byte Commander:

Observe que na command >file 2>&1ordem do redirecionamento é importante. Se você escrever command 2>&1 >file(o que normalmente não é o que você deseja), ele primeiro redirecionará o comando stdoutpara o arquivo e depois redirecionará o comando stderrpara o seu agora não utilizado stdout, para que ele apareça no terminal e você possa canalizá-lo ou redirecioná-lo novamente, mas não será gravado no arquivo.

> FILE 2>&1e &> FILEsão equivalentes. Veja 8.2.3.2. Redirecionamento de erros no Guia Bash para iniciantes, capítulo 8

O [n]>&wordé chamado de duplicação arquivo de saída descritor (ver ponto 2.7.6 do POSIX Shell idioma padrão). Este comportamento particular é característica de conchas, incluindo Bourne-like ksh, dashe bash; de fato, o padrão é baseado em torno de Bourne shell e ksh. Examinando os manuais tcsh e csh , eles aparentemente não fornecem a capacidade de duplicar qualquer descritor de arquivo, no entanto, a partir da descrição de >&, isso se comporta como &>em bash(isto é, redireciona erros e a saída normal para o arquivo).

Em sistemas como o * nix, incluindo o Ubuntu, você costuma ouvir que tudo é arquivo, ou melhor, um descritor de arquivos . A saída padrão é o descritor de arquivo constante 1 e o erro padrão é o descritor de arquivo 2. Portanto, > FILE 2>&1tecnicamente significa o descritor de arquivo duplicado 2 no descritor de arquivo 1. Em outras palavras, esta resposta :

O 2> & 1 diz ao shell para fornecer ao comando um descritor de arquivo 2 que é uma duplicata do descritor 1. (ou seja, stderr & stdout apontam para o mesmo fd).

A chave aqui é observar que o descritor 1 deve ser definido primeiro. Como o shell processa os redirecionamentos da ordem da esquerda para a direita, o comando command >FILE 2>&1diz ao shell para reconectar o stdout para commandentrar FILEprimeiro, e somente então o descritor 2 pode se tornar uma cópia de 1, ou seja, 1 e 2 apontam para o mesmo local - FILE.

Obviamente, isso vai além do erro padrão e da saída padrão. Como mostra esta resposta , fazendo3&>2

... você duplica (dup2) o filedescritor 2 no filedescriptor 3, possivelmente fechando o filedescriptor 3 se já estiver aberto

Exemplo de manipulação de descritores de arquivos, entre muitos, seria capturar a saída do dialogcomando na variável

Também é importante notar que isso &>é específico bash. Em zsheste se comporta da mesma, mas de acordo com a documentação, "... não tem o mesmo efeito que '> palavra 2> & 1' na presença de multios". Em conformidade com POSIX /bin/sh, isso seria tratado como redirecionamento regular com a colocação do comando em segundo plano. Consulte também: Existe algum código sh que não seja código bash sintaticamente válido? .

Veja também:

• Wiki de Greg: Descritores de Arquivos