
Entendi que temos dois métodos para redirecionar stdout e stderr para o mesmo arquivo. O primeiro método é:
ls -l /bin > ls-output.txt 2>&1
Como o autor deeste livroafirma: Usando este método, realizamos 2 redirecionamentos, primeiro redirecionamos stdout para ls-output.txt e depois redirecionamos stderr (descritor de arquivo 2) para stdout (usando o descritor de arquivo 1).
A ordem dos redirecionamentos é importante.
ls -l /bin 2>&1 >ls-output.txt
redirecionaria o stderr para a tela.
Minha pergunta é: como em muitas linguagens de programação, o comando foi projetado com algumas regras de associatividade e precedência em mente?ecomo lemos o comando enquanto o escrevemos na tela?equal é a sequência de execução backend do comando?
Aqui está o que penso sobre a sequência de execução: Primeiro, o comando ls -l /bin
envia sua saída para stdout e erro para stderr (qualquer um deles). Então, o stderr é redirecionado para stdout. (se houver algum erro, por exemplo: if ls -l /binn
for usado) Agora, o fluxo stdout contém um dos dois (saída ou erro) que então redireciona para o arquivols-saída.txt
Responder1
Os redirecionamentos são processados da esquerda para a direita. Quando você executa:
ls -l /bin >ls-output.txt 2>&1
o shell executa aproximadamente as seguintes operações internamente:
fork(); // Then in the child process:
fd = open("ls-output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0666);
dup2(fd, 1);
close(fd);
// 2>&1
dup2(1, 2);
Em seguida, ele executa o ls -l /bin
comando com esses anexos de descritores em vigor. Como você redireciona stdout
primeiro para o arquivo, o redirecionamento stderr
herda esse redirecionamento.
Se você fosse escrever
ls -l /bin 2>&1 >ls-output.txt
A ordem das operações seria invertida:
// 2>&1
dup2(1, 2);
// >ls-output.txt
fd = open("ls-output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0666);
dup2(fd, 1);
close(fd);
Isso se conecta stderr
ao original stdout
, que provavelmente será o terminal. Então ele redireciona stdout
para um arquivo; isso não tem efeito stderr
.