[buug] Best practices for stderr messages?

Nick Moffitt nick at zork.net
Mon Dec 13 02:26:19 PST 2010

Claude Rubinson:
> I'm not so interested in recommendations for formatting conventions
> (although that would also be welcome) but, more specifically,
> recommendations for phrasing, useful/conventional terminology, etc.  I
> find myself struggling to balance clarity and brevity and am wondering
> if somebody might have already talked about the issue.

It depends entirely on what you are using stderr *for*, unfortunately.
So many programs find stderr as a convenient reporting channel that it
can tend to get noisy.  

The big split I've found is basically this:

	1. Program results in files created/modified on filesystem.
	Stdout is used for status information and user prompts, and
	stderr is used for fault reporting.

	2. Program results in data spewed to stdout.  Stderr is used for
	any and all reporting to the user.

Some programs of course allow you to tailor this behavior.  For example,
wget is a bit of a chimera, because it allows you to either make
multiple files on disk or spew data to stdout, so it follows the stderr
usage from #2.  

Personally I've taken to using logging utilities for my stderr spew,
partly because it allows me to use the same code in a python module for
a daemon as for an interactive shell utility.  The result is that my
stderr output for the interactive tools tends to look very syslog-ish,
complete with timestamps, severity levels, and so forth.  I don't see
this as necessarily a bad trend.

	01234567 <- The amazing* Indent-O-Meter!
*: Indent-O-Meter may not actually amaze.

More information about the buug mailing list