Como eu poderia lembrar como usar o redirecionamento?

Question

Eu sei o que

  program > /dev/null 2>&1 

faz. Ele redireciona a saída para /dev/null e 2>&1 significa redirecionar a saída de erro no mesmo local para onde a saída é enviada.

Meu problema é que sempre tenho que pesquisar no Google porque nunca me lembro disso.

Então, eu tento &2>1 , 1>2& , 1>&2 ... Eu tento cada combinação até que eu pesquise no Google ...

Qual é o truque para lembrar facilmente?

    

Answer 1

A saída é melhor que o erro, por isso, vem primeiro (1 vs 2).

> é a abreviação de 'vai para'. À esquerda é o que eu quero enviar e à direita é onde eu quero enviá-lo. Já que 'where' é (quase) sempre um arquivo, algo como

program > /dev/null 2>1

redirecionaria para um arquivo chamado 1. Assim, o "e" comercial (&) modifica o arquivo para o descritor de arquivo.

Infelizmente, não encontrei meu próprio mnemônico, mas quando comecei a aprender * nix, encontrei essa maneira lógica de funcionar bem. Depois de algumas passagens, torna-se uma segunda natureza.

    

Answer 2

Um truque é apenas lembrar que 1 = saída padrão, 2 = erro padrão. Então:

2>&1 = fluxo de erro padrão entra no fluxo de saída padrão.
1>&2 = vice-versa.

Se você já programou em uma linguagem semelhante a C, é fácil lembrar o "e" comercial ( & ). Eu escolho pensar nisso como se referindo ao "endereço de" descritor de arquivo existente, para que você não altere o arquivo em si ou crie um novo.

    

Answer 3

Ver o & como um nó pode ajudar: pense no que você deseja fazer com a saída de 2, então 2> e vincule-o com 1, então 2>&1

    

Answer 4

Na verdade, depende de qual shell você está usando. Bash geralmente é muito indulgente e você pode simplesmente fazer:

program &> file

    

Answer 5

Vamos considerar estas três opções:

program  2>1
program  2>1& 
program  2>&1

O primeiro envia stderr para um nome de arquivo "1": depois de tudo, o bash espera redirecionar para um arquivo.

O segundo também redireciona para o mesmo arquivo, mas executa program no plano de fundo: é isso que significa um & à direita.

Isso deixa a terceira possibilidade como a única que faz sentido no universo bash para redirecionar para um identificador de arquivo.

Como lembrar qual é qual entre 0, 1, 2? Pense em executar um computador no console. Primeiro, você tem que digitar algo (0 = stdin). Então, você vê a saída (1 = stdout). Por fim e somente se algo der errado, você verá stderr (2).

    

Answer 6

Desenhe em seu papel de parede.

Agora, a sério, essa e outras coisas básicas que eu mantive esquecendo, então adicionei um menu de dicas rápidas para um aplicativo que desenvolvi e que uso diariamente. Você pode querer experimentá-lo ou usar algo como o gnote para manter uma nota.

    

Answer 7

Em relação à concha bash, acho que a melhor maneira de lembrar é entender o que está acontecendo.
Se tudo que você quer fazer é lembrar como obter o comando correto, você pode tentar

program > /results 2> /results

Isso é bom e óbvio, o que está acontecendo e é fácil de lembrar. ou seja,

• 1 STDOUT vai para /results
• 2 STDERR também está indo diretamente para /results

o problema é que isso não funciona como você esperaria. considere o seguinte:

arquivo

: /tmp/poem.txt

the quick brown fox jumped over the lazy dog

e execute o comando

grep "brown" /tmp/poem.txt NOT_A_FILE > /tmp/results 2> /tmp/results

então

$ cat /tmp/results
grep: NOT_A_FILE: No such file or directory
 lazy dog

o que aconteceu aqui?
Meu entendimento é bash setup o redirecionamento apontando o STDERR diretamente para o arquivo /tmp/results e por causa da natureza de > que faz 2 coisas

1. normalmente cria um novo arquivo - nesse caso, a oportunidade passou quando o bash passou por essa rotina no momento em que a saída é gerada.
2. insira diretamente no começo do arquivo. e não acrescentar como >> faz.

Portanto, neste caso STDERR, insere diretamente no início de /tmp/results substituindo a saída de STDOUT.
Nota: se você usou >> para anexar, você provavelmente poderia usar essa sintaxe.
No entanto, para corrigir o problema, é necessário - não redirecionar STDERR - para o arquivo diretamente, mas sim para mesclar a saída de STDERR no fluxo STDOUT, para que você não obtenha uma colisão. Usando o operador operador 2>&1 obtém isso

grep "brown" poem.txt NOT_A_FILE > /tmp/results 2>&1

O & permite que o bash diferencie de um arquivo chamado 1 e o descritor de arquivo 1 .
Para mim, a declaração 2>&1 explica exatamente o que está acontecendo - STDERR está sendo redirecionado no próprio STDOUT - e só acaba em /tmp/results porque é onde o STDOUT é apontado (quase como um efeito colateral). Ao contrário do que muitos guias afirmam, o que é que 2>&1 envia STDERR para onde o STDOUT é apontado. Se isso fosse verdade - você ainda teria o problema de sobrescrever.

Para mais informações, consulte - link