FERGUSON@TMASL.EXXON.COM (05/04/89)
A minute ago, I asked if there was a way to change input redirection on the fly from within a program. Is there a way to use stream_$errin? What is error input? Where does it come from? I tried an ios_$get on stream_$errin, and it told me that no data was available on that stream. If I could redirect standard input to a file, then I'd REALLY like to redirect error input to the keyboard, if errin is something I can use. Any ideas? Thanks again. Scott ferguson@erevax.bitnet
nazgul@apollo.COM (Kee Hinckley) (05/13/89)
In article <8905041532.AA06381@umix.cc.umich.edu> FERGUSON@TMASL.EXXON.COM writes: > >A minute ago, I asked if there was a way to change input redirection >on the fly from within a program. > >Is there a way to use stream_$errin? What is error input? Where does >it come from? I tried an ios_$get on stream_$errin, and it told me >that no data was available on that stream. > stream_$errin was a very nice concept which would have done exactly what you want. Unfortunately the SVID requires that when a program starts and opens a file, the file id must equal 3, (in other words, you must only have three streams open, and stream_$errin made 4). At SR10 we made it work such that OBJ files still got four streams, but COFF objects only got 3. Over time that hack will go away and all programs will only have the 3 standard streams. 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. -kee
GBOPOLY1@NUSVM.BITNET (fclim) (05/15/89)
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.