On Tue, March 25, 2008 11:50 am, Ralph Shumaker wrote: > 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. >> >> carl >> > > I know that Lan didn't ask this directly, but I think he's wondering why > only two output channels were implemented. At least *I* am wondering > that. Why not stout, sterr, and stmisc? >
Actually, I'm not wondering that, and here's why. I wondered that already about permissions being limited to owner-group-world, and a unix guru asked me to contemplate (1) what I would add, and (2) where I would cut off additions. It was a perfect zen question ... there is no answer. Then when $MS added stdprn and whatever the other was (M$ has 5, right?), I saw clearly what bull-crap it could easily become (kinda like the registry). Where do we stop? stdusb? stddvd? So today I fully agree with the old guru, if you want more (or finer grained) output, program it yourself. But I still don't like having stdout/stderr crapped up. Pipes (real pipes) are one of the unix glories, and they depend on people honoring stdout and stdin. Tcl throws an error if an exec call returns anything on stderr. This makes perfect sense as long as they're real errors. I can catch them and abort the program if I don't care what the error is, or parse the error return if some errors call for different handling. But if the program is using stderr to say "everything's still OK here, boss :-)" I lose that flexibility. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
