Path: utzoo!attcan!uunet!jarthur!usc!cs.utexas.edu!jsq
From: addw@phcomp.co.uk (Alain Williams)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-ID: <14102@cs.utexas.edu>
Date: 29 Oct 90 13:12:45 GMT
References: <13878@cs.utexas.edu> <14011@cs.utexas.edu> <14012@cs.utexas.edu> <14014@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Organization: Parliament Hill Computers Ltd
Lines: 36
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: addw@phcomp.co.uk (Alain Williams)

> I agree; it makes things like 
> 
> 	join <(prog1) <(prog2) > joined-output-of-progs-1-and-2
> 
> possible.
Such things are possible *now*, you don't need /dev/fd to do it, just an
intelligent shell that doesn't mind making & destroying fifos.

Anyway, the above wouldn't work with a straight /dev/fd as has been talked about
here recently. Why ? The trouble is that if /dev/fd contains files with
names "0", "1", ... "19", the programs prog1 & prog2 would both have a file
/dev/fd/1 as their stdout, join would see another /dev/fd/1.

What is really needed to do what is suggested above is for /proc to contain
an fd directory, thus the command line above would be ``re written'' by the
shell to something like:

	join /proc/1234/fd/1 /proc/1235/fd/1 > joined-output-of-progs-1-and-2
(where 1234 & 1235 are the process ids of prog1 and prog2).

If we adopt the /proc/nnn/fd idea, more questions are raised, for instance what
are the file permissions on /proc/nnn/fd ?

Let me remind the original purpose for which /dev/fd was proposed:
provide a mechanism whereby programs could handle `-' to mean stdin/out
as does cat, but without trying.

Alain Williams

+44 734 461232

phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.

Volume-Number: Volume 22, Number 7