Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: /dev/stdin for 4.3?
Message-ID: <5863@brl-smoke.ARPA>
Date: Fri, 15-May-87 16:43:50 EDT
Article-I.D.: brl-smok.5863
Posted: Fri May 15 16:43:50 1987
Date-Received: Sat, 16-May-87 17:01:10 EDT
References: <7359@brl-adm.ARPA> <5856@brl-smoke.ARPA> <6679@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 15

In article <6679@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>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.

I think this is perfectly acceptable for the /dev/fd device
semantics.  I think there should be an access check so that
the open() fails if you try to open for a mode not already
encompassed by the current fd, but that's all.

Norman tells me that the Nth (N >= 9) Edition UNIX now uses
the scheme I described.