Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.questions
Subject: Re: login gripes
Message-ID: <5720@brl-smoke.ARPA>
Date: Thu, 2-Apr-87 18:36:05 EST
Article-I.D.: brl-smok.5720
Posted: Thu Apr  2 18:36:05 1987
Date-Received: Sun, 5-Apr-87 04:34:14 EST
References: <8703231450.AA18626@ephemeral.ai.toronto.edu> <15831@sun.uucp> <553@westpt.usma.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 24

In article <553@westpt.usma.edu> bill@westpt.usma.edu (Bill Gunshannon) writes:
>In article <15831@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes:
>...
>Actually what is happening is ...

Before contradicting Guy Harris, you should be sure you know what
you're talking about, which in this case you didn't.  Guy was right,
and you were wrong.  There is a single character queue per terminal
(not counting multiplexing, which is a different topic), and all
that /dev/tty is is a canonical entry to the controlling terminal's
data queue.  "stdin" is actually not anything magic at all but is
just the STDIO buffered I/O library's name for its way of getting at
file descriptor 0, which has been opened on the specific /dev/tty*
then shared across the various getty/login/shell transitions.  Unless
there has been an I/O redirection (which involves closing the f.d.
and opening it on a different inode) or a change of controlling
terminal (rare except in job-control shells), /dev/tty will access
the same data queues as f.d.s 0, 1, and 2.  Do the following experiment:
	$ cat </dev/tty &
Then type in various shell commands, e.g. "ls", "echo hi", etc.
The shell (which has reprompted) and the "cat" process will fight
over your terminal input, which will end up going to whoever gets it
first.  (Type a couple of stream delimiters, usually ^D, to get out of
this funny state.)