Path: utzoo!attcan!uunet!cs.utexas.edu!jsq From: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins) Newsgroups: comp.std.unix Subject: Re: File system name space Keywords: More Info Please Message-ID: <14103@cs.utexas.edu> Date: 29 Oct 90 18:26:01 GMT References: <13132@cs.utexas.edu> <13219@cs.utexas.edu> <13689@cs.utexas.edu> <13775@cs.utexas.edu> <13878@cs.utexas.edu> <14012@cs.utexas.edu> <14014@cs.utexas.edu> <13878@cs.utexas.edu>, Sender: jsq@cs.utexas.edu Reply-To: arnold@audiofax.com Organization: AudioFAX Inc., Atlanta Lines: 63 Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman) X-Submissions: std-unix@uunet.uu.net Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins) In article <13878@cs.utexas.edu>, arnold@audiofax.com (that's me) writes lots of stuff about the wonders of /dev/fd, including this point: >|> Opening /dev/fd/7 is equivalent to doing a dup(7); In article <14012@cs.utexas.edu> craig@b11.ingr.com (Craig Presson) writes: >But for those of us without access to every Unix manual ever published >(I do have a Version 7 Volume 1), could you fill in a bit more on the >semantics of this hybrid /dev entry? Like what do you get when you open >"/dev/fd/7" and there is no open file using that slot? Does the system >make these entries "invisible" to processes not using them? Do you just >get a classic "It's an error from Unix, you're not supposed to understand" >type return? Or am I Missing Something? What happens when you do a dup(7) and 7 isn't a valid file descriptor? It returns -1 and errno is set to EBADF. So, something along those lines happens if you open /dev/fd/7, and 7 isn't open. Now, in article <14014@cs.utexas.edu> addw@phcomp.co.uk (Alain Williams) writes: >What happens if you do an ``ls -l'' on /dev/fd, do you see the fds which are >open to the ls program or all possible fds, even those which aren't opened ? Yes; the files in /dev/fd are character device files, with major and minor device numbers, just like the entries in /dev for all your ttys. The major number is for the fd device driver routine, and the minor number indicates which fd you're trying to open. It is a different animal than the /proc, which is mounted on an in-kernel filesystem. >> (In fact, in V8 - V10, /dev/stdin, /dev/stdout, /dev/stderr, and /dev/tty are >> links to /dev/fd/0, /dev/fd/1, /dev/fd/2, and /dev/fd/3, respectively. The >> last, in particular, is a nice generalization, and eliminates an ugly special >> case in the kernel; init just does one more dup.) > >I always thought that /dev/tty was a means of getting hold of the tty when >you couldn't be certain that 0,1,2 was connected to it. What you are really >saying is that the UNIX convention of 0,1,2 having ``pre defined uses'' be >extended to `3 always connected to the terminal and used for nothing else'. >It isn't a /dev/fd issue, it is a UNIX convention issue. Exactly! One of the major thrusts of recent versions of Research Unix has been to simplify, and become as minimalist as possible. By having fd 3 be the tty and /dev/tty a link to /dev/fd/3, the code in the kernel for doing /dev/tty goes away. >The other thing is the /dev/tty is a guaranteed way of getting the terminal >& not something else (that is why the passwd program uses /dev/tty). 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; it's entirely possible that a process can get started off with no controlling terminal if its parent closed all open files and did the appropriate incantations to set the process group. You're no worse off than before when /dev/tty was built into the kernel. -- Arnold Robbins AudioFAX, Inc. | Laundry increases 2000 Powers Ferry Road, #200 / Marietta, GA. 30067 | exponentially in the INTERNET: arnold@audiofax.com Phone: +1 404 933 7612 | number of children. UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 | -- Miriam Robbins Volume-Number: Volume 22, Number 8