Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!visdc!jiii
From: jiii@visdc.UUCP (John E Van Deusen III)
Newsgroups: comp.unix.wizards
Subject: Re: Reading from stderr
Message-ID: <508@visdc.UUCP>
Date: 15 Apr 89 00:26:56 GMT
References: <5437@lynx.UUCP>
Reply-To: jiii@visdc.UUCP (John E Van Deusen III)
Distribution: na
Organization: VI Software Development, Boise, Idaho
Lines: 34

In article <5437@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
> Am I in good company in believing that a program that reads from
> standard error is a naughty program?  It seems to be done (usually) as
> an alternative to the horrible drudgery of opening /dev/tty. ...

In one application that I have there is a program running in the middle
of a pipe line that sometimes forks an interactive shell.  Once I used

exec </dev/tty >/dev/tty

in order for the shell to access the terminal.  The problem was that if
the su command were subsequently invoked, the proper entry in
/etc/ttytype would not be found, and because of the way /etc/profile was
set up, TERM would be zapped.  So I changed my line to

exec 0<&2 1>&2

Of course I knew that the standard error file wasn't redirected.  It is
also possible to remember the name of your terminal in an environment
variable.  My point is that opening /dev/tty is NOT the same as
restoring your standard input and output to their condition prior to
redirection.

To do the same thing within a C program, you would close(2) fildes 0 and
use the dup(2) system call to return a fildes 0 with the save open file
as fildes 2.  The same process would apply to fildes 1.  Since file
descriptors 0, 1, and 2 are all opened with oflag set to O_RDWR, and
stderr is unbuffered, there shouldn't be any reason why you couldn't
read from fildes 2.  I agree with Mr. McNally that it is something I
would prefer not to do.
--
John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii