SURVEY RESULTS: Should fd 3 be /dev/tty?

[Dan Bernstein]

>  Should file descriptor 3 be, by new convention, /dev/tty?

The survey results are in, and they send clear messages to AT&T and
to Berkeley:

AT&T: Why does v8/v9 have fd 3 as another name for /dev/tty? There is
very little interest in or use for it. Those few applications that want
/dev/tty can open it themselves. You might make some people happy by
having a ``standard command input'' instead.

BERKELEY: Programmers *expect* that /dev/tty can be opened at any time.
But some BSD changes make this untrue. Make sure that it is true in
future releases. (Start by letting /dev/tty be opened while EXCL is set.)

I received responses from 26 people. Apologies for any errors in this list.

  pdb at SEI.CMU.EDU (Patrick Barron)
  flee at shire.cs.psu.edu (Felix Lee)
  haahr at bogey.princeton.edu (Paul Haahr)
  mark%jhereg at src.honeywell.com (Mark Colburn)
  bes%holin%mtune at att.att.com (Bradley Smith)
  ficc!peter at uunet.UU.NET (Peter da Silva)
  vlb at apple.com (Vicki Brown)
  taux01!amos at nsc.nsc.com (Amos Shapir)
  att!pegasus!hansen (Tony)
  n3dmc!johnl at uunet.UU.NET (John Limpert)
  att!cbosgd!alice!andrew
  sneaky!gordon at texbell.swbt.com (Gordon Burditt)
  ki4pv!cdis-1!tanner at ucf-cs.ucf.edu (T. Andrews)
  tbl at apollo.com
  @RELAY.CS.NET:andrew%frip.wv.tek.com at tektronix.tek.com (Andrew Klossner)
  jfc at ATHENA.MIT.EDU (John Carr)
  hznx at vax5.CCS.CORNELL.EDU (Dan Dulitz)
  auspex!auspex.com!guy at uunet.UU.NET (Guy Harris)
  gwyn at BRL.MIL (Doug Gwyn)
  arnold at mathcs.emory.edu (Arnold Robbins)
  talos!kjones at uunet.UU.NET (Kyle Jones)
  sco!seanf at ucscc.UCSC.EDU (Sean Fagan)
  jbuck at epimass.epi.com (Joe Buck)
  bzs at bu-cs.BU.EDU (Barry Shein)
  @pucc:brossard%litsun2.epfl.ch at CLSEPF51.bitnet (Alain Brossard)
  nazgul at apollo.com (Kee Hinckley)

The responses can be broken down as follows:

  3 It's already in AT&T's v8/v9
  2 Yes, a standard command-input stream would be useful
  1 Why not?
  4 Why?
  3 No, but a standard command-input stream would be useful
 11 No

The basic problem here is that ``control terminal'' is a fundamental
part of a process state, deemed important enough to have an entry in
the u area but not important enough to have easy user-level access.
Rather than having ioctls doing the dirty work, there should be
explicit system calls to detach from, attach to, and gain a file
descriptor for control terminals. In general u area information is
accessible through system calls, and only non-process state information
is relegated to device drivers and ioctls; I don't see why ttys are
handled differently.

Soapbox aside, below is a discussion of each point brought up.
Parenthesized numbers indicate the frequency of each argument.

(5) What do you do with processes having no control terminal:   The easy
answer is to have fd 3 be closed. When you reattach, you reopen fd 3.

(8) You can open /dev/tty in any case, and the extra effort necessary
is negligible:   If it were always possible to open /dev/tty, this would
be a valid argument, but in current BSD releases many special features
(TIOCEXCL being the one where this most annoys me) eliminate the ability
to open /dev/tty. If this is fixed, then I'll agree that there's no
point of making fd 3 be /dev/tty.

(5) Many programs, and the SVID, assume that a program starts with
exactly fds 0, 1, and 2 open:   This is a valid argument against
writing bad code and against the SVID. Seriously, any change that
breaks old programs (and standards) should be considered carefully.
Listen, AT&T!

(6) Having an extra file descriptor for ``command input'' would be
useful if it is redirectable:   I agree completely and would love
the subsequent simplification in more, awk, make, etc. Under the
current one-input two-output model, it is simply impossible to
write a ``standard'' program to interleave two inputs. Changing
the standard model to two-input two-output is a potentially very
useful generalization.

(3) v8/v9 already has fd 3 as /dev/tty:   Why? AT&T, if you want
to make this change, go all the way and accompany stdin, stdout,
and stderr with cmdin. Don't make a non-redirectable file descriptor
for what's already in the name space.

(2) Don't waste a file descriptor:   Very few programs would suffer
from this waste.

(2) Use stderr for /dev/tty like some versions of more do:   stderr
is redirected very often, and it may not be readable.

(1) Use stderr for cmdin, and make it readable:   If stderr is
redirected, it is rarely to the same place as where you want
command input from. It doesn't make sense to force input and
output to be the same place.

(1) Since fd 3 can be redirected, it is insecure for programs like
passwd, su, etc. to trust fd 3 to be /dev/tty:   Since the advent
of pseudo-terminals this argument has been moot.

(1) ``If fd 0 isn't a terminal the program shouldn't ask any more
questions'':   Say goodbye to more.

(2) Standard errors could go anywhere, not just /dev/tty:   The
two people who made this argument thought I was asking ``should fd 2
be /dev/tty?'' Nobody's proposing changing stderr.

In summary, *if* it is always possible to open /dev/tty, people don't
really need it as a file descriptor. It may be useful to change the
basic model of stdin-stdout-stderr to stdin-stdout-stderr-cmdin,
although that wasn't the original question.

---Dan Bernstein, bernsten at phoenix.princeton.edu