Thanks for the clarification Dave. I definitely appreciate the problem of tools 
overusing stderr -- I've run into it, and much of my Cronic support email is 
about the problem.

However, I don't thinking adding a global stderr suppression option is a good 
idea. Here's my reasons:

Principle - Suppressing error output will miss important diagnostic messages. 
Not all stderr output is accompanied by an error-code. In particular, warnings 
are stderr output that don't prevent a tool from succeeding. Typical examples 
of warnings are deprecation warnings from interpreters/compilers, or security 
config warnings. Cronic should always assumes that any tool or script may 
succeed, but output warnings at any time.

Social - I fear a global suppression option would quickly become the 
"recommended" usage for Cronic, which would defeat much of its utility. At the 
first sign of trouble, users will search around and find the global suppression 
option, rather then address the specific tool's problem.

Practical - The extraneous stderr output can be suppressed locally in cron 
scripts by redirect the tool's stderr to stdout, or elsewhere. For example:

gitlab-ctl ... 2>&1

Or the one-liner version with eval:

cronic eval 'gitlab-ctl ... 2>&1'

Of course, it is important to realize that one is kludging or bodging the 
problem here, and true warnings or errors may be missed. The only real solution 
is to fix the tool. At least by using the ugly "2>&1", the misbehaving tool is 
clearly marked.

Cheers - Chuck

Reply via email to