I missed that. It's actually a much bigger problem.
stdout and stderr(or) is two output paths to explicitly diverge error logs and problems from standard output.
stdout / stdin is reserved for user interaction, informational messages (md5sum), actual output (ls, less, etc.), and the like. OTOH, stderr is explicitly for error messages only, and it's very useful (and necessary).
A real use case from my daily job: I'm an administrator of a large system (approx ~1K servers), and I have substantial amount of cattle, and a lot of pets [0]. All of these servers have cron jobs, and other automated tasks on them. All servers can mail to a local mail server to report us problems, so our cron automatically mails any outputs to us.
All the tools we use, and scripts we write have the following properties:
- If everything is OK, they are silent by default.
- They output to stderr, if anything notable happens.
- Also we copy (think tee) all stderr to their respective logs (both local and on a centralized server).
Now consider:
- The (e-mail, log) noise if all the tools were writing their outputs to stdout.
- The work required to silence all tools. What if they don't have any --quiet switches?
- Furthermore, they wrote everything to stderr. How can I know whether thing has worked as it should?
- How can I find the problem quickly if everything is written to "Error" log?
- Furthermore how can I revise the errors happened quickly? Info & Error on the same file. grep galore!
- How can I silent a tool (by redirecting to /dev/null) if both normal and error logs are written via stderr?
These are the simple problems that I can come up on a real, big production system in five minutes. I can find more problematic scenarios which will happen on a daily basis, if I think more.
All these conventions, folklore, recommended usage and facilities are in place because of the needs and the experience acquired in the history of these systems. Running around them amok, just because they enable color, pretty spinners, or justify some narrow usage scenario is not correct.
These conventions and philosophy [1] allowed *NIX systems to scale without needing excessive administrative elbow grease. Ignoring these, and developing tools which use facilities and conventions as they please will degrade the ability to manage these systems with minimal work. I can always grep, but it will be inefficient and not guaranteed to get everything that I want, and also it will cost me and the computer time to do so.
Like algorithms, systems are easier to manage when "n" is small. When "n" gets big, these tasks got really hard, really fast.
The article does specifically recommend using stderr for messages to the user, is there any reason that would kill scriptability?