Path: utzoo!attcan!uunet!ginosko!usc!rutgers!dptg!att!cbnewsl!ams
From: ams@cbnewsl.ATT.COM (andrew.m.shaw)
Newsgroups: comp.unix.wizards
Subject: Re: how can I get filename from file descriptor?
Message-ID: <1607@cbnewsl.ATT.COM>
Date: 24 Aug 89 14:47:28 GMT
References: <9340@chinet.chi.il.us>
Reply-To: ams@cbnewsl.ATT.COM (andrew.m.shaw,580,)
Organization: AT&T Bell Laboratories
Lines: 45

In article <9340@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>In article <19208@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>
>>>Have the FILE structure have a name field in it:
>>>    char *name;
>>>then when the fopen() call is made, have it fill in the field ....
>
>>This is all well and good, but you will have to define what happens
>>when you ask for the name of stdin, stdout, stderr, or a file opened
>>with fdopen.  (Also, but rather incidentally, I am not terribly thrilled 
>>with the idea of fopen having to call getwd.)
>
>It would _almost_ be worthwhile to have open() store the pathname of
>the thing being opened so that it could be retreived by some sort
>of fcntl(), just like it would almost be worthwhile to store a
>per-process cwd.  The problem would be that these pathnames are
>subject to change if someone mv's or rm's any of the components and
>it's probably not worth the effort to keep them updated.
>
>Les Mikesell

I partially disagree - when you are in the process opening the file,
you already know the name of the node.  If you are a member of a pipeline,
you probably shouldn't know the name of the file; building code that
depends on whether file descriptor 1 is /dev/console, a pipe, or nohup.out,
is not a practice to be encouraged: casual use defeats the entire "a
device is just a file" paradigm.  And as for trying to determine the
file name of an inherited file descriptor 5, well, what kind of program
is this?

What would be really nice, however, is to have some way of attaching
file descriptors from outside a process: e.g. a process could run cu(1)
and then get the file descriptor for its own use (arbitrary protocols
implemented over dial-ups without net* programming and re-implementing
uucp).  Thus:
	...
	switch (pid=fork())
	case 0:		<exec cu>
	default:	linefd = fdattach (pid, 3);
	...
This is still horrible, in that you have to know that fd=3 is what cu
has as its line, and therefore has a high break potential, but at least
it would solve the original problem and be more general besides.

		Andrew Shaw