Um sinalizador “--silent” deve suprimir avisos e erros, ou apenas avisos?

Question

Estou criando um aplicativo baseado em terminal e quero implementar um sinalizador --silent para suprimir o ruído se ele não desejar.

Neste aplicativo, os erros são mais comumente registrados quando o aplicativo não pode executar uma tarefa necessária, avisos são registrados quando algo não pode ser executado, mas o aplicativo ainda pode operar.

Então, isso dito, deve um sinalizador --silent suprimir avisos e erros, ou apenas avisos? Qual é a convenção geral sobre isso?

Em ruby , ruby -w0 desativa avisos para seu script (informações via ruby --help )

Mas em curl , curl --silent suprime a saída all .

    

Answer 1

Como você vê com curl / ruby , não há uma convenção genereal. Depende muito da sua aplicação e do que pode dar errado com ela. Também depende de como é usado. Para algumas aplicações, faz sentido ter --quiet e --really-quiet flags, para alguns é apenas um exagero. Além disso, um sinalizador --really-quiet geralmente não é necessário tecnicamente, já que você pode descartar todas as mensagens com 2>/dev/null . Como diretrizes gerais, sugiro o seguinte:

• Tenha um código de retorno significativo. Se o seu aplicativo puder separar diferentes classes de erro (como erro do usuário, erro externo), ter códigos de retorno diferentes e documentá-los.

• Se o seu aplicativo puder produzir muitos avisos, tenha um sinalizador para filtrar apenas os avisos. Se o seu aplicativo tiver níveis de log diferentes (como INFO, NOTICE, WARNING, ERROR), tenha um sinalizador para filtrá-los. (Como: -q , -qq , -qqq .)

• Se o seu aplicativo for usado principalmente de forma interativa, suprima os avisos, mas não os erros. Especialmente se o aplicativo não parar após o erro.

• Se o seu aplicativo for usado principalmente em uma configuração automática, suprima os avisos e erros, porque ninguém está olhando para eles de qualquer maneira. Mas somente se o aplicativo parar após esse erro e produzir um código de retorno significativo.