On Sat, March 22, 2008 1:11 pm, SJS wrote: > 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? >
Absolutely nothing you've said makes me think they're doing the right, or even the sane thing. Among other things, it means that anyone using their programs as building blocks now has to parse the stderr output to determine if an error, indeed, has occured. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
