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
