O que é considerado como “ideal” em relação ao uso de stdout / stderr para saída em situações diferentes?

Question

Eu vi stdout e stderr usados de diversas maneiras - até onde eu entendo, é comum usar stdout para informações gerais e stderr para erros e afins. No entanto, também vi stderr usado para enviar mensagens de informação relacionadas ao programa em si (mas não relacionadas a erros, avisos, depuração, etc.) e para fins de depuração (suponho que este último use o fluxo de erros para que possa ser filtrado para auxiliar na depuração) e stdout para os avisos mais sérios que eu teria pensado que teriam pertencido em stderr .

Então, eu estava imaginando - quando é visto como ideal usar stdout ou stderr em relação ao que o programa está produzindo, além da saída geral e erros? É mais dependente do programa ou mais genérico do que isso?

    

Answer 1

O motivo para ter separado stdout e stderr em primeiro lugar é distinguir entre a saída de dados do programa (que pode ser armazenada em um arquivo, alimentada para um pipeline, & c.) e diagnósticos e fluff ( que são realmente de interesse para um operador humano olhando para o terminal). (Não há nenhuma maneira automática de fazer o mesmo para entrada, mas você pode fazer isso com um pouco mais de dificuldade abrindo e lendo o dispositivo de terminal de controle em vez de stdin .) Assim, se você tiver escolha entre escrever algo em stdout ou stderr , a melhor heurística é provavelmente "Esses dados serão de interesse de outro programa usando minha saída?" No entanto, isso pode ser dependente de programa e aplicativo e, portanto, não há uma regra de substituição única. (É por isso que há opções de substituição, como 2>&1 e assim por diante em bash .)

    

Answer 2

Depende! Um fator relevante é que stderr é unbuffered por padrão, já que alguém não gostaria de perder uma mensagem de erro ao buffer quando algo falha, enquanto stdout é line (terminal) ou block (caso contrário) bufferizado por padrão. Isso é mais eficiente, embora as falhas possam causar a perda de uma linha ou blocos de dados. Outra é o que o programa produz; se algo estiver emitindo um formato específico, digamos, CSV ou JSON, misturar mensagens de erro que possam corrompê-lo (ou exigir codificação no formato específico e, em seguida, o que acontecerá se houver um erro ao codificá-lo nesse formato abortar! abort! abort! ), enquanto em outros casos (um sistema de tipo de menu interativo?) misturar mensagens de erro com outra saída pode não importar tanto.

    

Answer 3

Sempre pense que alguém colocará seu programa em um pipeline em algum momento:

$ inputProducer | yourProgram | outputConsumer

Ao considerar direcionar algo para stderr ou stdout , o que importa é se esse algo é relevante para (um genérico) outputConsumer ou se isso tornaria sua vida mais difícil.

• Relevante: stdout
• Irrelevante: stderr

( Tenha em atenção que muitos relatórios de erros vão para stdout em vez de stderr porque as pessoas se esquecem de redirecioná-lo para stderr , embora essa tenha sido a melhor escolha. )