Resposta # 1: Corrida conflito
head nofile text1 1> output.txt 2> output.txt # --
I know this won't work.'
Isso realmente funciona, mesmo que não seja como você esperava e não cumpre o seu propósito.
Você tem dois descritores de arquivo que serão redirecionados independentemente para o mesmo arquivo de saída com > output.txt
.
Um descritor de arquivo agirá mais rápido: ele criará o arquivo output.txt e começará a escrever nele.
Quando o segundo descritor de arquivos começar a agir, ele recriará o mesmo arquivo ( > output.txt
), apagando o que está dentro.
Você perderá a primeira parte escrita pelo primeiro descritor de arquivo, se houver algum.
Espere uma saída distorcida, especialmente com saídas longas. Veja esta resposta também .
Considere que o comportamento nem sempre é reproduzível. No meu sistema, hoje, o arquivo é criado com o erro dentro como uma primeira linha e o texto depois.
head nofile text1 1> output.txt 2>&1 # ok this works
Isso funciona porque primeiro você altera o redirecionamento da saída padrão para o arquivo output.txt
. Então você pede para redirecionar o erro padrão para o mesmo destino da saída padrão, que significa o arquivo output.txt
.
Resposta # 2: assuntos de ordem
O core da resposta: bash redirecionando não é comutativo significa que pedidos são importantes :
head nofile text1 2>&1 1> output.txt
head nofile text1 2>&1> output.txt
Aqui antes que você peça para redirecionar o erro padrão para o destino saída padrão (provavelmente o atual tty ). Então você pede para mudar somente a saída padrão para o arquivo de saída output.txt
. (ambos os comandos 1>output.txt
e >output.txt
agem da mesma maneira). O erro padrão permanece redirecionado onde estava antes (provavelmente o atual tty ).