0

I'm designing a terminal-based application, and I want to implement a --silent flag to suppress noise if they don't want it.

In this application, errors are most commonly logged when the application cannot perform a necessary task, warnings are logged when something couldn't be performed, but the application can still operate.

So, that stated, should a --silent flag suppress warnings and errors, or just warnings? What is the general convention on that?

In ruby, ruby -w0 turns off warnings for your script (information via ruby --help)

But in curl, curl --silent supresses all output.

2

As you see with curl / ruby, there is no genereal convention. It greatly depends on your application and what can go wrong with it. It also depends on how it is used. For some application it makes sense to have --quiet and --really-quiet flags, for some it's just overkill. Also a --really-quiet flag is usually not required technically, as you can throw away all messages with 2>/dev/null. As general guidelines I suggest the following:

  • Have a meaningfull returncode. If your application can destinguish different error classes (like user error, external error), have different returncodes and document them.

  • If your application can produce lots of warnings, have a flag to filter only warnings. If your application has different loglevels (like INFO, NOTICE, WARNING, ERROR), have a flag to filter them. (Like: -q, -qq, -qqq.)

  • If your application is used mostly interactivly, suppress warnings but not errors. Especially if the application does not stop after the error.

  • If your application is used mostly in an automatic setting, suppress warnings and errors, because nobody is looking at them anyway. But only if the application stops after that error and produces a meaningfull returncode.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy