Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!genrad!decvax!harpo!seismo!hao!hplabs!sri-unix!mark.umcp-cs@udel-relay From: mark.umcp-cs%udel-relay@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: question about getpass Message-ID: <2120@sri-arpa.UUCP> Date: Mon, 13-Jun-83 23:10:03 EDT Article-I.D.: sri-arpa.2120 Posted: Mon Jun 13 23:10:03 1983 Date-Received: Wed, 15-Jun-83 19:22:28 EDT Lines: 29 From: Mark WeiserFrom: Dave Johnson WRONG! You can't open /dev/tty "exclusive mode" (I assume you mean the TIOCEXCL ioctl). The device /dev/tty simply indirects to the specific tty that is you control terminal (usually the one you are logged on to) and has no struct tty of its own within the kernel. If you TIOCEXCL /dev/tty, you really end up setting the exclusive use bit on your own terminal, NOT on /dev/tty itself. This will not prevent some OTHER user from opening /dev/tty. It will only prevent you (or some other user or process) from opening the specific terminal that is your control terminal... Whoops, I didn't realize my answer would be misunderstood. Of course dave is right, /dev/tty is essentially a different device for everyone who opens it. I assumed this was understood, and was thinking of a context in which one wished to run something like 'su' but wanted it to read from stdin (e.g. to have a shell script to become super-user or some other horrible thing). In this case you somehow want the getpasswd call in su to fail to be able to open /dev/tty and so use stdin. My own context was a window system I built in which stdin and stdout had been redirected to the windows, and everything worked great except for silly little programs like su which INSISTED on opening /dev/tty. But of course, that's what its there for...