semantics of /dev/tty?
Guy Harris
guy at auspex.UUCP
Sun Feb 12 07:52:43 AEST 1989
>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".
More information about the Comp.unix.questions
mailing list