Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq
From: ske@pkmab.se (Kristoffer Eriksson)
Newsgroups: comp.std.unix
Subject: /dev/tty implemented as /dev/fd/3
Summary: Differences from the old implementation?
Message-ID: <14162@cs.utexas.edu>
Date: 30 Oct 90 09:12:25 GMT
References: <14014@cs.utexas.edu> <13878@cs.utexas.edu> <14103@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Peridot Konsult i Mellansverige AB, Oerebro, Sweden
Lines: 24
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: ske@pkmab.se (Kristoffer Eriksson)

[ I don't quite understand why the submittor wants to split this from the
thread of Re: File system name space, but let's give it a try and see what
happens, eh?  -mod ]

In article <14103@cs.utexas.edu> arnold@audiofax.com writes:
>In general, unless someone went to the trouble, fd 3 will be attached to the
>terminal, so opening /dev/tty is pretty safe.  Nothing's foolproof; [...]
>You're no worse off than before when /dev/tty was built into the kernel.

If you have a program that closes only fd 3, this implementation will behave
differently from the old /dev/tty device implementation, won't it? You will
not be able to reach the controlling terminal by a guaranteed route, in spite
of the fact that it is still available on other fd-s. Or is the controlling
terminal concept implemented in such a way that closing fd 3 is the same as
disassociating from the controlling terminal (so you won't be bother with
terminal interrupts and such) ?
-- 
Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden
Phone: +46 19-13 03 60  !  e-mail: ske@pkmab.se
Fax:   +46 19-11 51 03  !  or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske

Volume-Number: Volume 22, Number 13