O que são stdin, stdout e stderr no Linux?
stdin, stdout e stderr são três fluxos de dados criados quando você inicia um comando do Linux. Você pode usá-los para saber se seus scripts estão sendo canalizados ou redirecionados. Mostramos a você como.
Fluxos ingressam em dois pontos
você começa a aprender sobre sistemas operacionais Linux e Unix, você encontrará os termos stdin, stdout e stederr. Estes são três fluxos padrão que são estabelecidos quando um comando do Linux é executado. Na computação, um fluxo é algo que pode transferir dados. No caso desses fluxos, esses dados são texto.
Os fluxos de dados, como os fluxos de água, têm dois fins. Eles têm uma fonte e uma saída. Qualquer comando do Linux que você esteja usando fornece uma extremidade de cada fluxo. A outra extremidade é determinada pelo shell que iniciou o comando. Esse fim será conectado à janela do terminal, conectado a um pipe, ou redirecionado para um arquivo ou outro comando, de acordo com a linha de comando que lançou o comando.
O Linux Standard Streams
No Linux, stdin é o fluxo de entrada padrão. Isso aceita texto como sua entrada. A saída de texto do comando para o shell é fornecida por meio do fluxo stdout (saída padrão). Mensagens de erro do comando são enviadas através do fluxo stderr (erro padrão).
Assim, você pode ver que existem dois fluxos de saída, stdout e stderr, e um fluxo de entrada, stdin. Como as mensagens de erro e a saída normal têm suas próprias condutas para transportá-las para a janela do terminal, elas podem ser manipuladas independentemente uma da outra.
Os fluxos são tratados como arquivos
Fluxos no Linux - como quase todo o resto - são tratados como se fossem arquivos. Você pode ler texto de um arquivo e pode escrever um texto em um arquivo. Ambas as ações envolvem um fluxo de dados. Assim, o conceito de lidar com um fluxo de dados como um arquivo não é tão grande.
Cada arquivo associado a um processo recebe um número exclusivo para identificá-lo. Isso é conhecido como o descritor de arquivo. Sempre que uma ação é necessária para ser executada em um arquivo, o descritor de arquivo é usado para identificar o arquivo.
Esses valores são sempre usados para stdin, stdout e stderr:
- < li> 0: stdin
- 1: stdout
- 2: stderr
Reagindo a Canos e Redirecionamentos
Para facilitar introdução de alguém a um assunto, uma técnica comum é ensinar uma versão simplificada do tópico. Por exemplo, com a gramática, nos é dito que a regra é "eu antes de E, exceto depois de C." Mas, na verdade, há mais exceções a essa regra do que há casos que a obedecem.
Na mesma linha, quando se fala de stdin, stdout e stderr, é conveniente traçar o axioma aceito de que um processo não sabe nem se importa com o término de seus três fluxos padrão. Um processo deve se importar se sua saída está indo para o terminal ou sendo redirecionada para um arquivo? Ele pode até mesmo dizer se a sua entrada está vindo do teclado ou está sendo canalizada para ele de outro processo?
Na verdade, um processo sabe - ou pelo menos pode descobrir, se ele escolher verificar - e pode mudar seu comportamento de acordo se o autor do software decidir adicionar essa funcionalidade.
Podemos ver essa mudança de comportamento com muita facilidade. Experimente estes dois comandos:
ls
ls | cat
O comando ls se comporta de maneira diferente se sua saída (stdout) estiver sendo canalizada para outro comando. É o ls que muda para uma saída de coluna única, não é uma conversão realizada pelo gato. E ls faz o mesmo se a saída está sendo redirecionada:
ls > capture.txt
cat captura.txt
Redirecionando stdout e stderr
Há uma vantagem em ter mensagens de erro entregues por um fluxo dedicado. Isso significa que podemos redirecionar a saída de um comando (stdout) para um arquivo e ainda ver quaisquer mensagens de erro (stderr) na janela do terminal. Você pode reagir aos erros se precisar, conforme eles ocorrem. Ele também impede que as mensagens de erro contaminem o arquivo no qual o stdout foi redirecionado.
Digite o seguinte texto em um editor e salve-o em um arquivo chamado error.sh.
[ PRE] #! / Bin / bash echo "Sobre para tentar acessar um arquivo que não existe" cat bad-filename.txt
Torne o script executável com este comando:
chmod + x error.sh
A primeira linha do script ecoa o texto para a janela do terminal, através do stdout corrente. A segunda linha tenta acessar um arquivo que não existe. Isto irá gerar uma mensagem de erro que é entregue via stderr.
Execute o script com este comando:
./ error.sh
Podemos ver que ambos os fluxos de saída, stdout e stderr, foram exibidos nas janelas do terminal.
Vamos tentar redirecionar a saída para um arquivo:
./ error.sh > capture.txt
A mensagem de erro que é entregue via stderr ainda é enviada para a janela do terminal. Nós podemos verificar o conteúdo do arquivo para ver se a saída stdout foi para o arquivo.
cat captura.txt
A saída de stdin foi redirecionado para o arquivo como esperado.
O > O símbolo de redirecionamento funciona com stdout por padrão. Você pode usar um dos descritores de arquivo numérico para indicar o fluxo de saída padrão que deseja redirecionar.
Para redirecionar explicitamente o padrão, use esta instrução de redirecionamento:
1 >
Para redirecionar explicitamente o stderr, use esta instrução de redirecionamento:
2 >
Vamos tentar nosso teste novamente, e desta vez usaremos 2 & gt ;:
./ error.sh 2 > capture.txt
A mensagem de erro é redirecionada e a mensagem stdoutecho é enviada para a janela do terminal:
Vamos veja o que está no arquivo capture.txt.
cat captura.txt
A mensagem stderr está em capture.txt como esperado.
Redirecionando stdout e stderr
Certamente, se pudermos redirecionar stdout ou stderr para um arquivo independentemente um do outro, devemos ser capazes para redirecionar os dois ao mesmo tempo, para dois arquivos diferentes?
Sim, nós podemos. Este comando direcionará o stdout para um arquivo chamado capture.txt e stderr para um arquivo chamado error.txt.
./ error.sh 1 > capture.txt 2 > error.txt
Como os dois fluxos de saída padrão de saída e erro padrão são redirecionados para os arquivos, não há saída visível na janela do terminal. Nós retornamos ao prompt de linha de comando como se nada tivesse ocorrido.
Vamos verificar o conteúdo de cada arquivo:
cat capture. txt
[PRÉ] cat error.txt
Redirecionando stdout e stderr para o mesmo arquivo
Isso é legal, nós ' Cada um dos fluxos de saída padrão vai para o seu próprio arquivo dedicado. A única outra combinação que podemos fazer é enviar stdout e stderr para o mesmo arquivo.
Podemos conseguir isso com o seguinte comando:
./ error.sh > capture.txt 2 & 1 > 1
Vamos quebrar isso.
- ./ error.sh: Inicia o arquivo de script error.sh.
- 2 > & 1: usa o & > instrução de redirecionamento. Essa instrução permite que você informe ao shell para fazer um fluxo chegar ao mesmo destino que outro fluxo. Nesse caso, estamos dizendo “redirecionar o fluxo 2, stderr, para o mesmo destino para o qual o fluxo 1, stdout, está sendo redirecionado”.
Não há saída visível. Isso é encorajador.
Vamos verificar o arquivo capture.txt e ver o que está nele.
cat capture.txt
Os fluxos stdout e stderr foram redirecionados para um único arquivo de destino.
Para que a saída de um fluxo seja redirecionada e jogada silenciosamente, direcione a saída para / dev / null.
Detectando o redirecionamento dentro de um script
Discutimos como um comando pode detectar se algum dos fluxos está sendo redirecionado e pode optar por alterar seu comportamento de acordo. Podemos fazer isso em nossos próprios scripts? Sim, nós podemos. E é uma técnica muito fácil de entender e empregar.
Digite o seguinte texto em um editor e salve-o como input.sh.
#! / Bin / bash if [-t 0]; então ecoar stdin vindo do teclado else echo stdin vindo de um pipe ou um arquivo fi
Use o seguinte comando para torná-lo executável:
chmod + x entrada.sh
A parte inteligente é o teste dentro dos colchetes. A opção -t (terminal) retorna true (0) se o arquivo associado ao descritor de arquivo terminar na janela do terminal. Usamos o descritor de arquivo 0 como argumento para o teste, que representa stdin.
Se stdin estiver conectado a uma janela de terminal, o teste será verdadeiro. Se stdin estiver conectado a um arquivo ou pipe, o teste falhará.
Podemos usar qualquer arquivo de texto conveniente para gerar entrada para o script. Aqui estamos usando um chamado dummy.txt.
./ input.sh < dummy.txt
A saída mostra que o script reconhece que a entrada não vem de um teclado, mas sim de um arquivo. Se você quiser, pode variar o comportamento do script de acordo.
Isso foi com um redirecionamento de arquivo, vamos tentar com um pipe.
[ PRE] cat dummy.txt | ./input.sh
O script reconhece que sua entrada está sendo canalizada para ele. Ou mais precisamente, ele reconhece mais uma vez que o fluxo de stdin não está conectado a uma janela de terminal.
Vamos executar o script sem canalizar nem redirecionar.
./nome.sh
O fluxo stdin é conectado à janela do terminal, e o script relata isso de acordo.
Verifique a mesma coisa com o fluxo de saída, precisamos de um novo script. Digite o seguinte em um editor e salve-o como output.sh.
#! / Bin / bash if [-t 1]; então o echo stdout está indo para a janela do terminal else echo stdout está sendo redirecionado ou canalizado fi
Use o seguinte comando para torná-lo executável:
chmod + x input.sh
A única mudança significativa para este script está no teste entre colchetes. Estamos usando o dígito 1 para representar o descritor de arquivo para stdout.
Vamos testá-lo. Vamos canalizar a saída através de cat.
./ output | cat
O script reconhece que sua saída não vai diretamente para uma janela de terminal.
Também podemos testar o script redirecionando a saída para um arquivo.
./ output.sh > capture.txt
Não há saída para a janela do terminal, estamos silenciosamente retornando ao prompt de comando. Como nós esperávamos.
Podemos ver o arquivo capture.txt para ver o que foi capturado. Use o seguinte comando para fazer isso.
cat captura.sh
Mais uma vez, o teste simples em nosso script detecta que o fluxo stdout não está sendo enviado diretamente para uma janela de terminal.
Se executarmos o script sem nenhum canal ou redirecionamento, ele deverá detectar que a stdout está sendo entregue diretamente à janela do terminal.
PRE] ./ output.sh
E é exatamente isso que vemos.
Fluxos de consciência
]Saber como saber se os seus scripts estão conectados à janela do terminal, ou a um pipe, ou estão sendo redirecionados, permite que você ajuste o comportamento deles de acordo.
As saídas de log e diagnóstico podem ser mais ou menos detalhado, dependendo se está indo para a tela ou para um arquivo. Mensagens de erro podem ser registradas em um arquivo diferente da saída normal do programa.
Como geralmente é o caso, mais conhecimento traz mais opções.
Via: How to Geek
Veja Também:
Nenhum comentário