Os relatórios de progresso / informações de registro pertencem ao stderr ou stdout?

Existe uma orientação oficial POSIX, GNU ou outra orientação sobre onde os relatórios de progresso e as informações de registro (coisas como "Fazendo o foo; o foo feito") devem ser impressos? Pessoalmente, costumo escrevê-los no stderr para poder redirecionar o stdout e obter apenas a saída real do programa. Recentemente me disseram que isso não é uma boa prática, pois os relatórios de progresso não são realmente erros e apenas as mensagens de erro devem ser impressas no stderr.

Ambas as posições fazem sentido e, é claro, você pode escolher uma ou outra, dependendo dos detalhes do que está fazendo, mas eu gostaria de saber se existe um padrão comumente aceito para isso. Não consegui encontrar nenhuma regra específica no POSIX, nos padrões de codificação GNU ou em qualquer outra lista de boas práticas amplamente aceita.

Temos algumas perguntas semelhantes, mas elas não abordam exatamente esse problema:

• Quando usar o redirecionamento para stderr em scripts de shell : A resposta aceita sugere o que eu costumo fazer, mantenha a saída final do programa em stdout e qualquer outra coisa em stderr. No entanto, isso é apresentado apenas como uma opinião do usuário, embora apoiada por argumentos.

• A mensagem de uso deve ir para stderr ou stdout? : Isso é específico para ajudar mensagens, mas cita o padrão de codificação GNU. Esse é o tipo de coisa que estou procurando, mas não restrito a ajudar apenas as mensagens.

Portanto, existem regras oficiais sobre onde os relatórios de progresso e outras mensagens informativas (que não fazem parte da produção real do programa) devem ser impressos?

O Posix define os fluxos padrão assim :

Na inicialização do programa, três fluxos devem ser predefinidos e não precisam ser abertos explicitamente: entrada padrão (para leitura de entrada convencional), saída padrão (para gravação de saída convencional) e erro padrão (para gravação de saída de diagnóstico). Quando aberto, o fluxo de erro padrão não é totalmente armazenado em buffer; os fluxos de entrada e saída padrão são totalmente armazenados em buffer se, e somente se, o fluxo puder ser determinado para não se referir a um dispositivo interativo.

A GNU C Library descreve os fluxos padrão da mesma forma:

Variável: FILE * stdout
O fluxo de saída padrão, usado para saída normal do programa.

Variável: FILE * stderr
O fluxo de erros padrão, usado para mensagens de erro e diagnóstico emitidos pelo programa.

Portanto, as definições padrão têm pouca orientação para o uso do fluxo além da "saída convencional / normal" e da "saída de diagnóstico / erro". Na prática, é comum redirecionar um ou ambos os fluxos para arquivos e pipelines, onde os indicadores de progresso serão um problema . Alguns sistemas até monitoram stderr a saída e a consideram um sinal de problemas. Informações de progresso puramente auxiliares são, portanto, problemáticas em qualquer fluxo.

Em vez de enviar indicadores de progresso incondicionalmente para qualquer fluxo padrão, é importante reconhecer que a saída do progresso é apropriada apenas para fluxos interativos . Com isso em mente, recomendo escrever contadores de progresso somente após verificar se o fluxo é interativo (por exemplo, com isatty()) ou quando ativado explicitamente por uma opção de linha de comando. Isso é especialmente importante para que os medidores de progresso que dependem do comportamento de atualização do terminal façam sentido, como barras com% concluído.

Para certas mensagens de progresso muito simples ("Iniciando X" ... "Concluído com X"), é mais razoável incluir a saída mesmo para fluxos não interativos. Nesse caso, considere como os usuários podem interagir com os fluxos, como pesquisar com grepou paginar com lessou monitorar com tail -f. Se fizer sentido ver as mensagens de progresso nesses contextos, elas serão muito mais fáceis de consumir stdout.

POSIX define erro padrão como

para escrever saída de diagnóstico

Isso não limita seu uso apenas a mensagens de erro. Eu consideraria as informações de progresso como saída de diagnóstico, portanto elas pertencem ao erro padrão.

O POSIX é um pouco mais concreto sobre "informações de diagnóstico" no Shell e Utilitários , 1.4: Padrões de Descrição do Utilitário (ênfase minha):

STDERR

A seção STDERR descreve a saída de erro padrão do utilitário. Somente as mensagens enviadas propositadamente pelo utilitário são descritas. O uso de um terminal para erro padrão pode fazer com que qualquer um dos utilitários padrão que grava a saída de erro padrão pare quando usado em segundo plano. Por esse motivo, os aplicativos não devem usar recursos interativos em scripts para serem colocados em segundo plano.

O formato das mensagens de diagnóstico para a maioria dos utilitários não é especificado, mas as convenções de idioma e cultura das mensagens informativas e de diagnóstico cujo formato não é especificado neste volume do POSIX.1-2008 devem ser afetadas pela configuração de LC_MESSAGES e [XSI] [Option Start ] NLSPATH. [Fim da opção]

A saída de erro padrão especificada dos utilitários padrão não deve depender da existência ou do valor das variáveis ​​de ambiente definidas neste volume do POSIX.1-2008, exceto conforme fornecido por este volume do POSIX.1-2008.

Comportamento padrão : Quando esta seção está listada como "O erro padrão deve ser usado apenas para mensagens de diagnóstico.", Significa que, a menos que seja especificado de outra forma, as mensagens de diagnóstico serão enviadas ao erro padrão somente quando o status de saída indicar que um erro ocorreu e o utilitário é usado conforme descrito por este volume do POSIX.1-2008.

Quando esta seção está listada como "Não utilizado", significa que o erro padrão não deve ser usado quando o utilitário for usado conforme descrito neste volume do POSIX.1-2008.

IANASL, mas interpreto que isso signifique que o stderr terá saída apenas se o utilitário retornar um código de saída de erro. Como esse não deve ser o curso normal dos eventos para uma execução bem-sucedida, nenhuma informação de progresso deve ser impressa por um utilitário POSIX, a menos que ocorra um erro (a menos que, é claro, se especificado de outra forma, etc.).

Pelo princípio da exclusão, ele só pode ir para o stderr. Sim, eu sei que você perguntou sobre uma especificação oficial, que não posso apresentar além do link para a especificação POSIX, fornecida por Stephen Kitt, que afirma que stderr é para fins de diagnóstico.

O ponto mais importante é que stdin e stdout têm uma função que desaprova a impressão de relatórios de progresso para stdout - eles naturalmente formam a sequência de pipes que, nos comandos shell do Unix, não é apenas um efeito colateral, mas o cerne da poderosa abordagem de pipelining .

Assim. Nada, exceto a "carga útil" real do seu programa, pertence ao stdout. Se o seu programa não tiver saída, nada deve ser levado ao stdout. Isso deixa o stderr para todo o resto , incluindo relatórios de progresso.

É verdade que isso deixa um buraco - provavelmente seria bom ter um "stdfluff" ou algo parecido que não serve para saída nem erros, mas para relatórios de progresso, depuração e algo assim. De fato, nada impede você de fazer isso, ou seja, você pode imprimir seu progresso no descritor de arquivo 3. Exemplo:

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'

Isso não produz saída. (*)

$ perl -e 'open($fd, ">", "/dev/fd/3"); print $fd "hello\n"'  3>&1
hello

Isso imprime em fd-3, que é redirecionado para stdout.

(*) O primeiro exemplo não produz saída, mas ainda é um pouco rebuscado; a openfalha e $!conteria no such file or directory; apenas tome isso como um exemplo, é claro que não deve ser usado dessa maneira a sério. Em um programa real, se você quiser seguir esse caminho, poderá testar se /dev/fd/3é utilizável e usar isso como uma dica para ativar seus relatórios de progresso; você teria que fazer isso bem cedo para não se confundir com seus próprios openarquivos reais e coisas assim ...

A mensagem de uso deve ir para stdout se o usuário a tiver chamado --helpe stderr se tiver cometido um erro. Imprimir no stderr incondicionalmente é desagradável, pois torna mais difícil visualizá-lo com um pager / grep / etc.

Além disso, posso sugerir uma terceira maneira: abra / dev / tty para relatórios de progresso / spinners / etc.