File system name space

[Arnold Robbins]

Submitted-by: arnold%audiofax.com at mathcs.emory.edu (Arnold Robbins)

In article <13878 at cs.utexas.edu>, arnold at 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 at cs.utexas.edu> craig at 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 at cs.utexas.edu> addw at 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 at 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