Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: semantics of /dev/tty?
Keywords: stat /dev/tty
Message-ID: <1001@auspex.UUCP>
Date: 11 Feb 89 21:52:43 GMT
References: <1181@mina.liu.se>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 26

>Q1: Why does fstat() (and stat()) fail this "synonym" requirement?

Because "/dev/tty" is only a "synonym device" in the sense that it's
implemented by a plain, ordinary, boring driver that just happens to
take "open", "read", "write", "ioctl", and "select" requests and calls
the appropriate routine for the *real* device.  Opening "/dev/tty"
doesn't give you a handle on the real tty device, i.e. one on which the
aforementioned calls directly call the underlying driver; it gives you a
handle on the "/dev/tty" driver, which turns the aforementioned calls
into calls on the real device.

"fstat" and "stat" don't go down to the device driver, so it has no
opportunity to do the indirection for you.  This is almost certainly a
feature, not a bug.

>Q2: Given that fstat() is useless for the purpose of determining operational
>equivalence between two (terminal) file descriptors, what would be the `best'
>way to implement this test? I have hacked up a temporary solution using
>ioctl() calls to see whether a change in one terminals line discipline also
>changed the other's. Are there any better (i.e. less kludgey)
>solutions?

Well, you could "fstat" "fd", 0, *and* then "stat" "/dev/tty", and see
if the "st_rdev" from "fd" matches *either* the one from 0 (or whatever
file descriptor happens to be guaranteed to be attached to your
terminal) *or* the one from "/dev/tty".