Path: utzoo!attcan!uunet!cs.utexas.edu!jsq
From: arnold@mathcs.emory.edu (Arnold Robbins)
Newsgroups: comp.std.unix
Subject: Re: File system name space
Message-ID: <14137@cs.utexas.edu>
Date: 30 Oct 90 15:12:19 GMT
References: <13878@cs.utexas.edu> <14011@cs.utexas.edu> <14012@cs.utexas.edu> <14014@cs.utexas.edu> <14102@cs.utexas.edu>
Sender: jsq@cs.utexas.edu
Reply-To: arnold@audiofax.com
Organization: AudioFAX Inc., Atlanta
Lines: 69
Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman)
X-Submissions: std-unix@uunet.uu.net

Submitted-by: arnold@mathcs.emory.edu (Arnold Robbins)

In article <14102@cs.utexas.edu> addw@phcomp.co.uk (Alain Williams) writes:
>> 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.

Yes, up to a point.  What happens though if you do

	nohup join <(prog1) <(prog2) > joined-output-of-progs-1-and-2 &

and then log out?  The temporary fifos will still be around when the
program finally exits and the shell won't be around to clean them up.
A cron job of some sort could maybe do it, but it's still not as clean
as /dev/fd.

>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.

No.  The programs have their respective file descriptors 1 attached as pipes,
by the shell via dup, to other "files" in /dev/fd.  The join program would see

	join /dev/fd/4 /dev/fd/5

on its command line.  The scheme requires both /dev/fd and knowledge by the
shell to work completely.  Graphically, you have

	prog1[fd1]>------\
			  \
		     join[fd4][fd5][fd1]--> output
				/
	prog2[fd1]>-----------/

>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 ?

As explained above, this already happens.  Permissions on /dev/fd/* should be
666 since no process can affect any other's file descriptors.

>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.

That's exactly what existing implementations do.  Having ported a version of
a /dev/fd driver into NFS based systems, and used KSH with process substitution
turned on, I can say from experience that it works just fine.  It is such
a nice thing to have that I make gawk (gnu awk) recognize file names of that
type internally and "do the right thing" even if the underlying system does
not support /dev/fd.
-- 
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 11