Reading from stderr

[Mike McNally]

In article <508 at visdc.UUCP> jiii at visdc.UUCP (John E Van Deusen III) writes:
>In article <5437 at lynx.UUCP> m5 at lynx.UUCP (Mike McNally) writes:
>> [ asking about reading from stderr vs. 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. . .

Gosh all hemlock!  I guess I just found an incompatibility between our
OS and UNIX.  When I open "/dev/tty" on my (non-UNIX) machine, the
"driver" for "/dev/tty" does some magic happy stuff and gets the
current control device info, and returns a dup'ed file descriptor for
that.  Thus, when I look at the device number via fstat(), I get the
real tty beef.

Oh well, I guess I should change the question a little:  what's the
advantage of having "/dev/tty" behave the way it does in this respect?
That is, would a massive catastrophe occur if a file descriptor
returned from an open request on "/dev/tty" was a real honest-to-gosh
dup of the control tty file descriptor?  (Not that I'm suggesting that
UNIX be changed; I just need to know if I really ought to bother to
break a feature that turns out to be a compatibility issue.)

-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.