Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!att!ulysses!andante!alice!dmr
From: dmr@alice.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: SURVEY RESULTS: Should fd 3 be /dev/tty?
Message-ID: <9323@alice.UUCP>
Date: 7 May 89 05:05:59 GMT
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 64

The survey for which Bernstein gives the results (8123@phoenix.Princeton.EDU)
has slid off our netnews directory, but the answers seem to suggest
misconceptions about the way /dev/tty works in the Ninth Edition
system.  Since our scheme seems to work conveniently, and differently
from most other contemporary systems, I'll describe it.  However, since
I don't remember the question that was originally asked, this may not
answer it.

In V9, there are special files named /dev/fd/0, /dev/fd/1 etc.
They do not have devices associated with them; instead opening
one of them causes an internal dup(2) of the corresponding already-open
file.  For convenience, /dev/stdin is linked to /dev/fd/0 and so
things like `cmd | cat hdr /dev/stdin trlr' can be used without
having to put special conventions (like a `-' argument) into
commands.

/dev/tty is linked to /dev/fd/3, and the programs that create login
sessions make file descriptor 3 refer to the terminal just like
descriptors 0,1,2.  (The standard such program is /etc/init, but there
are also the network connection acceptors).  Inheritance of file 3
takes place by the usual mechanism.

The advantage of the scheme is that the notion of `controlling
terminal' can be mostly removed from the kernel.  By an explicit
request, a process may ask that it become a process group leader, and
that any signals generated by a particular stream should be sent to
its process group.  However, a process does not need to remember this
stream.  We keep it for convenience (it is printed by ps) but the
information isn't used in the kernel.

The notion of /dev/tty is a peculiar one, because programs are run in
many environments, and programs have their own ideas of what they
want.  The essence is a way of getting to the user's terminal in spite
of I/O redirection; for example, as a matter of policy, programs that
read passwords should strongly encourage people to type them in
directly rather than storing them in files.  However, programs run in
the background (for example with &, or via cron or at) may not have a
terminal in any useful sense.

Our scheme of making the descriptor for the terminal merely one of the
several conventionally-available ones has, on balance, given rise to
fewer surprises and misbehaviors than previous attempts that wired the
notion into the kernel.  Such surprises as do occur can be debugged and
understood by tools and reasoning already familiar to users, and don't
depend on special kernel algorithms that determine the meaning of
/dev/tty.  Many Unix variants exhibit peculiar behaviors when /dev/tty
is tied to a special association of a control terminal and a process
(for example, non-working signals when you reuse an incoming line with
an old process on it, or a daemon process taking over your terminal
line.)

At the same time, we're aware that one can view this scheme as yet
another step in an infinite regress--perhaps in a couple of years
people will learn that file 3 can be redirected too, and we might need
file 4 to really, REALLY refer to the terminal.

The fact that file descriptor 3 was picked was a matter of choosing a
convenient convention.  Indeed, at first we used the largest permitted
file descriptor.  Because this varied, it seemed simpler to switch to
the lowest free descriptor.

	Dennis Ritchie
	att!research!dmr
	dmr@research.att.com