Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ukma!wuarchive!cs.utexas.edu!jsq
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: /dev/tty implemented as /dev/fd/3
Message-ID: <14205@cs.utexas.edu>
Date: 1 Nov 90 02:29:47 GMT
References: <14103@cs.utexas.edu> <14162@cs.utexas.edu> <14188@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 28
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)

In article <14188@cs.utexas.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>It is a different issue. There are objective advantages to eliminating
>/dev/tty, kernel controlling terminals, and POSIX sessions: the kernel
>becomes noticeably smaller, the POSIX standard becomes several pages
>thinner and a lot easier to implement, programmers no longer have to
>worry about special system calls to manipulate the tty fd, non-orphaned
>processes in orphaned process groups are not killed off unnecessarily,
>etc.

I think the fundamental problem is that P1003 leaned too much in the
direction of "the system as seen by the user" as opposed to the system
as seen by applications.  Therefore, 1003.1 specified support for BSD-
like job control (as an option, but NBS made it mandatory in the FIPS).
But clearly BSD-like job control is a horrible kludge.  In a superior
environment with /proc and a good multiple-process-managing user
interface, better (and definitely cleaner) implementations of "job
control" are easy to accomplish.  It is the single-tty-channel model
that pretty much forced the signal-based design of the BSD approach,
along with the extra kernel support (that never was gotten fully right
in any implementation I've ever seen, although HP/UX may have been
close).

I agree with the sentiment that such kludgery should be phased out of
the system interface standard.

Volume-Number: Volume 22, Number 16