Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!tektronix!percival!qiclab!sopwith!snoopy
From: snoopy@sopwith.UUCP (Snoopy)
Newsgroups: comp.unix.wizards
Subject: Re: SURVEY RESULTS: Should fd 3 be /dev/tty?
Message-ID: <172@sopwith.UUCP>
Date: 5 May 89 03:00:09 GMT
References: <8123@phoenix.Princeton.EDU>
Reply-To: snoopy@sopwith.UUCP (Snoopy)
Distribution: usa
Organization: The Daisy Hill Puppy Farm
Lines: 33

In article <8123@phoenix.Princeton.EDU> bernsten@phoenix.Princeton.EDU (Dan Bernstein) writes:

|(6) Having an extra file descriptor for ``command input'' would be
|useful if it is redirectable:   I agree completely and would love
|the subsequent simplification in more, awk, make, etc. Under the
|current one-input two-output model, it is simply impossible to
|write a ``standard'' program to interleave two inputs. Changing
|the standard model to two-input two-output is a potentially very
|useful generalization.
|
|(3) v8/v9 already has fd 3 as /dev/tty:   Why? AT&T, if you want
|to make this change, go all the way and accompany stdin, stdout,
|and stderr with cmdin. Don't make a non-redirectable file descriptor
|for what's already in the name space.

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.

A second input stream could be useful for other things besides commands,
perhaps call it auxin?

So, how about: stdin, auxin, stdout, stderr, and auxout ?

    _____     
   /_____\    Snoopy	"My dot-matrix does Postscript."
  /_______\   
    |___|     tekecs.gwd.tek.com!sopwith!snoopy		 qiclab!sopwith!snoopy
    |___|     sun!nosun!illian!sopwith!snoopy		parsely!sopwith!snoopy