mikpe@mina.liu.se (Mikael Pettersson) (02/11/89)
Let me begin with a quote from the man page for tty(4):
The file /dev/tty is, in each process, a synonym for that
process' controlling terminal.
Well, I have come to the conclusion that this is not quite true.
Consider the case where a program tries to determine whether as given
file descriptor `fd' denotes the controlling terminal (*). One strategy
might be to fstat() both `fd' and `0' (assuming that standard input
is connected to the terminal of course) and then check whether they both
produce the same value in the `st_rdev' field in their stat structs.
However, if `fd' comes from an open() on "/dev/tty", fstat() will
report the <major,minor> of /dev/tty, *not* the ones of the controlling tty.
Q1: Why does fstat() (and stat()) fail this "synonym" requirement?
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?
/Mike
--
(*) This is not just an academic problem: I have a very much real-world
application (part of a run-time system) that really *needs* this functionality.
--
Mikael Pettersson, Dept of Comp & Info Sci, University of Linkoping, Sweden
email: mpe@ida.liu.se or ..!{mcvax,munnari,uunet}!enea!liuida!mpeguy@auspex.UUCP (Guy Harris) (02/12/89)
>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".
dhesi@bsu-cs.UUCP (Rahul Dhesi) (02/13/89)
In article <1001@auspex.UUCP> guy@auspex.UUCP (Guy Harris) writes: >"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. It is almost certainly a feature, not a bug, except in one situation. That situation occurs when a site logs out idle users based on the access time of each user's /dev/ttyxx device, and a user happens to be using C-Kermit, which opens /dev/tty leaves /dev/ttyxx inactive during file transfers. There seems to be no way for a process (even a root process) to find access/modification times for the /dev/tty of another process. This could be considered a bug. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: bsu-cs!dhesi@iuvax.cs.indiana.edu
wcs@skep2.ATT.COM (Bill.Stewart.[ho95c]) (02/20/89)
In article <5655@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > It is almost certainly a feature, not a bug, except in one situation. > That situation occurs when a site logs out idle users based on the > access time of each user's /dev/ttyxx device, and a user happens to be > using C-Kermit, which opens /dev/tty leaves /dev/ttyxx inactive during > file transfers. Idle-daemons are EVIL! Suppose you have an intelligent terminal, (blit, pc, 3270 :-), whatever) and are working in local mode - you may not touch either /dev/tty or /dev/ttyxx for a long time, because you're trying to get your graphics to look perfect, and the idle daemon decides you've walked away without logging off. Bad news! Also, the general rule about idle-daemons is that any idle-daemon that makes an intelligent decision about whether you're really there or not can be fooled by users, and any one that doesn't will trash people who are working. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # # News. Don't talk to me about News.