On Tue, March 25, 2008 10:12 am, Carl Lowenstein wrote: > On Tue, Mar 25, 2008 at 9:40 AM, Lan Barnes <[EMAIL PROTECTED]> wrote: >> >> On Tue, March 25, 2008 6:58 am, Paul G. Allen wrote: >> > Lan Barnes wrote: >> >> 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? >> >> >> > >> > In addition to what SJS said, sometimes stdout will not work because >> > output may be redirected. An example might be a CGI script where >> stdout >> > would be redirected to the client browser. In such a case, it's >> usually >> > not desirable to send error messages to the client, so they are sent >> to >> > stderr, which is on the local machine. Many GUI apps may not be able >> to >> > display errors via stdout either, so stderr is used. >> > >> > stderr is generally the correct place to send error messages. >> > >> > PGA >> >> I don't think I made myself clear. Yes, errors should go to stderr. >> What >> I'm complaining about is when "hey, everything's going great :-)" >> messages >> are sent to stderr, making error checking in my calling scripts a joke. >> > > You don't want "everything's going great" messages to get mixed in > with the standard output, do you? Strange stuff in the output, which > in principle might be piped to another program, is worse than strange > stuff in the error messages. >
As has already been remarked by me, you, and others on this thread, silence is a perfectly adequate "everything's going great" message. And if not, -V or (for rpm), -h can give reassuring and educational ourput to stdout. To repeat the subject line, "Sending anything but errors to stderr sucks." -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
