O que significa exatamente no redirecionamento de saída?

Question

Eu vejo coisas como command 1> out ou com 2>&1 para redirecionar stderr, mas às vezes eu também vejo &> por si só, etc.

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

    

Answer 1

O & em 2>&1 simplesmente 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 redirecionaria os erros para um arquivo chamado 1 , mas se você usar 2>&1 , ele o enviaria para o standard output stream .

Isso &> diz para enviar ambos, standard output e 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 koko com o seguinte conteúdo:

   #!bin/bash
   
   ls j1
   echo "koko2"
   

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

3. Agora observe que j1 não existe

4. Agora execute ./koko &> output

5. execute cat output e 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 novamente, mas desta vez assim:

./koko > output

Faça cat output e você verá apenas koko2 como. Mas não a saída de erro do comando ls j1 . Isso será enviado para o standard error que você verá no seu terminal.

Nota importante graças ao @Byte Commander:

Observe que, em command >file 2>&1 , a ordem do redirecionamento é importante. Se você escrever command 2>&1 >file (que normalmente não é o que você deseja), ele primeiro redirecionará o stdout do comando para o arquivo e depois redirecionará o stderr do comando para seu stdout , que não é usado, então ele mostrará no terminal e você poderia canalizá-lo ou redirecioná-lo novamente, mas ele não será gravado no arquivo.

    

Answer 2

> FILE 2>&1 e &> FILE são equivalentes. Consulte 8.2.3.2. Redirecionamento de erros do Guia de Bash para Iniciantes Capítulo 8

    

Answer 3

O [n]>&word é chamado de Duplicando Descritor de Arquivo de Saída (veja seção 2.7 .6 do padrão de idioma do shell POSIX). Esse comportamento específico é uma característica de shells semelhantes a bourne, incluindo ksh , dash e bash ; na verdade, o padrão é baseado em torno do shell Bourne e ksh . Analisando tcsh e csh manuais, eles aparentemente não fornecem capacidade de duplicar qualquer descritor de arquivo, porém a partir da descrição de >& , isso se comporta como &> em bash (isto é, redireciona erros e saída normal para arquivo).

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

% bl0ck_qu0te%

A chave aqui é observar que o descritor 1 precisa ser definido primeiro. Como o shell processa os redirecionamentos na ordem da esquerda para a direita, o command >FILE 2>&1 diz ao shell para reconectar o stdout para command ir para FILE primeiro e somente então o descritor 2 pode se tornar cópia de 1, que é 1 e 2 ponto para o mesmo localização - FILE .

Isso, claro, vai além do erro padrão e da saída padrão. Como mostra esta resposta , fazendo 3&>2

% bl0ck_qu0te%

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

Também vale notar que &> é específico de bash . Em zsh isso se comporta da mesma forma, mas de acordo com a documentação, "... não tem o mesmo efeito que "> palavra 2 > & amp; 1 'na presença de multios". Em /bin/sh compatível com POSIX, isso seria tratado como redirecionamento regular ao colocar o comando em segundo plano. Veja também Existe algum código sh que não seja código sintático sintaticamente válido? .

Veja também:

• O Wiki de Greg: descritores de arquivo