Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!NUSVM.BITNET!GBOPOLY1
From: GBOPOLY1@NUSVM.BITNET (fclim)
Newsgroups: comp.sys.apollo
Subject: Re: More on STDIN and EOF & Redirection
Message-ID: <8905150220.AA09330@umix.cc.umich.edu>
Date: 15 May 89 02:19:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 33
X-Unparsable-Date: Mon, 15 May 89 09:57:22 SST

Hi,
     In article <432facc0.1b147@apollo.COM>,  nazgul%apollo.uucp@eddie.mit.edu
(Kee Hinckley) writes

>stream_$errin was a very nice concept ... [stuff > /dev/null]
>
>All is not lost however.  You can have your program open the device
>/dev/tty and it will do what you want when you read and write to it.
>The main disadvantage to this is to the user, since they can't
>bypass whatever you were doing and redirect /dev/tty like they could
>with errin.

I agree that stream_$errin is (or was) a good concept.  It would make
things consistent; if there is a errout for stdout, there should be
a errin for stdin.

However, I would be very glad when I receive SR10.  I would like my
program have more control over where it can spit; whether the user redirect
both stdout and stderr.  Put it this way, stdout is for warnings; stderr
is for errors; while /dev/tty is for fatal end-of-the-world errors which
I would like the user to see instead of stashing them away in some file.
If the user wish a transcript of these fatal errors, he could use script(1).

Furthermore, if the programmer opens /dev/tty for reading, he plans it
thataway; he does not wish the user to redirect his input from a file.

"I need a fix 'cos I am going down"  -- John Lennon

fclim          --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu
computer centre
singapore polytechnic
dover road
singapore 0513.