begin quoting Lan Barnes as of Sat, Mar 22, 2008 at 12:56:18PM -0700: > Why why WHY do programmers send informational messages to stderr? It makes > it really difficult to script calls to the program that check for errors. > What is it about the "err" in stderr that they don't understand?
Sometimes what's desired is unbuffered output, so stdout won't do. Sometimes a tool is being used that colors stdout differently than stderr; so an easy way to make some messages stand out is to print 'em to stderr. Sometimes the programmer wants to see informational/status messages without bothered with all the output, so the stuff the programmer is currently interested in goes to stderr, and everything else goes to stdout, and thus a nice little filter is possible merely by using "programname > /dev/null". Perhaps your programmers aren't returning an error code when there's an error (a better way to check for errors)? For JUnit tests (Java), I've implemented a little capture-stdout-and-stderr tool, so that I can verify output conditions in the unit tests... any test that emits output to stderr during a successful test gets its test wrapped in my little widget, and the test gets updated to assert that indeed, nothing was written to stderr. Of course, that test fails, but now it can be *checked* that there's no stderr output if there's no error. I really think this sort of thing should be in the junit framework, but what's a clean way of doing so? -- Most likely they're just being lazy, like me. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
