Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <6679@mimsy.UUCP>
Date: Thu, 14-May-87 13:30:29 EDT
Article-I.D.: mimsy.6679
Posted: Thu May 14 13:30:29 1987
Date-Received: Sat, 16-May-87 11:28:54 EDT
References: <7359@brl-adm.ARPA> <5856@brl-smoke.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <5856@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) writes:
>[/dev/stdin] is almost trivial:
> 1) Implement /dev/fd instead (general file descriptor device) ....
> 2) All you need is the open() entry ... just like a dup() except
>	you don't allocate anything.
>I've seen several implementations but none this simple.

Ours was, until Fred decided that the semantics were a bit odd.
Now they are odder.  Consider:  A dup()ed file descriptor shares
a seek pointer with another; an open()ed file descriptor does not.
A dup()ed file descriptor shares its read/write access status with
another; an open()ed descriptor does not.  But if opening /dev/fd/n
duplicates file descriptor n, suddenly open()ed file descriptors
share seek pointers and access status.  In particular, this means
you cannot open /dev/fd/5 for reading if file descriptor 5 is
currently open only for writing.

Anyway, if the descriptor refers to an inode, it is easy enough
to re-open() it.  If it refers to a socket, it must be dup()ed, as
there is nothing to open.  I would say that this is an argument
in favour of always doing a dup(), but Fred insisted. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris