Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bu-cs!bzs
From: bzs@bu-cs.BU.EDU (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: SURVEY RESULTS: Should fd 3 be /dev/tty?
Message-ID: <30752@bu-cs.BU.EDU>
Date: 6 May 89 15:32:13 GMT
References: <8123@phoenix.Princeton.EDU> <172@sopwith.UUCP>
Distribution: usa
Organization: Boston U. Comp. Sci.
Lines: 27


>Can I insert my pet peeve here?  There is also a need for a standard
>auxiliary output.  stderr is often pressed into service for non-error
>output.  I claim that this is a bad thing.  It is a pain to scan through
>verbose output checking for error messages.  There should be a standard
>place to send a 2nd data stream seperate from the error messages.
>I run into this problem much more frequently than the case of needing
>two input streams.

I think we're missing the spirit here and getting too literal minded
(ie. that some messages sent to stderr aren't errors, that isn't
exactly why it was called stderr.)

It would probably be better to just write programs to use some sort of
character tag at the beginning so you could de-mux the different types
of messages at the other end with grep rather than reworking all of
Unix to solve this problem. Granted that doesn't help with previously
written code you can't change. TWENEX used some sort of chars like %
for informatory, # for error or some such thing (but, of course, they
didn't have pipes or grep so it wasn't as handy as it might be in a
unix program.)
-- 

	-Barry Shein, Software Tool & Die

There's nothing more terrifying to hardware vendors than
satisfied customers.