Hacker News Reader

Comment by bjourne | Hacker News Reader

Stderr is nice in theory. In practice, it is really hard to consistently decide which types of output should go on stdout and which should go on stderr. Different developers (all experienced unixians) have different ideas on when stderr should be used instead of stdout. For example should stderr be used for --help, --version or when invalid arguments are passed to a program?

Then there's the problem with granularity. An output for a long running program could be purely informative, minor warning, major warning, minor error, critical error or some other category. Putting all those outputs on stderr doesn't simplify anything for a script that would still need to parse the output and determine what to do with it.

View on HN

There is no such difficulty. I give you the GNU Coding Standards section on Command-Line Interfaces.[1] It will inform you of what you should do on any Linux/Unix system: --help and --version both go to stdout, never stderr, because it is not an error to do what the user requested, successfully. Any program which prints to stderr on either of these options, and/or returns a failure code, deserves a patch.

Someone will come and say this is all well and good for GNU but what if we aren't using GNU? The answer is the same, because at least in this case the GNU conventions are sane and consistently applicable to virtually all command-line programs.

When invalid arguments are passed to a program, of course it should print to stderr, and exit unless it can do something smarter or prefers to ignore the options (most programs wouldn't).

The issue of severities has no bearing on stdout vs. stderr. If you have a syslog-like severity system, all those messages can go to the same stream (probably a file or the network, but it could be stderr).

Before anyone says things should be done another way, please point us to some examples of popular programs that do not abide by the above on a Linux/Unix system. Most do, and all should, and it's not so difficult.

[1] http://www.gnu.org/prep/standards/standards.html#Command_002...

But sometime it is obvious. For example, when binary output is being spewed to stdout.

Yeah, but that breaks the rule that standard error is for error messages. You're then repurposing stdout and stderr to "standard binary output" and "standard various text messages output".

There is nothing wrong with sending binary (non-textual) output to stdout. Many programs, like the netpbm utilities, work like this.

That's what yuhong meant, I think. If your stdout output is binary, it's clear that all user-readable messages should go to stderr.

Reply on news.ycombinator.com