Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!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: <1639@cbnewsl.ATT.COM>
Date: 25 Aug 89 22:38:18 GMT
References: <9353@chinet.chi.il.us>
Reply-To: ams@cbnewsl.ATT.COM (andrew.m.shaw,580,)
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 73


 In article <9353@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
 >In article <1607@cbnewsl.ATT.COM> ams@cbnewsl.ATT.COM (andrew.m.shaw,580,) writes:
 >
 >>>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()
 >
 >>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?
 >
 >Don't be silly - virtually every program you run checks to see if its
 >output is a tty in order to set its buffering behaviour appropriately.
 >This is a basic need that already has its solution built into stdio.
 
 Right, and the implementation doesn't depend on the *NAME* of the thing
 at all - only its characteristics: does it respond to ioctl(TCGETA)?
 
 >>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.
 >
 >This would be better solved by making cu able to run subshells with
 >their fd's redirected arbitrarily.  That should be almost trivial
 >to add and would not require additional OS support.
 
 So, by having the cu(1) source you have solved exactly 1 instance of the
 general problem.  A mechanism to grab arbitrary file descriptors solves
 the problem for once and for all, without requiring people to have the
 source for every utility they want to connect to.
 
 >What I had in mind was the magic involved in certain open()/close()
 >routines.  Suppose you are a cpio-like program that wants to handle
 >multiple volumes.  How can you do that if some other program (the
 >shell) has opened the device via redirection?
 
 You open() and close() the device.  Failing that, you use the ioctls
 provided by the driver and check the return code.  Why are you interested
 in the name?
 
 >...What if you need to twiddle the handshake lines on a tty device?
 
 Once, again, you use ioctl().
 
 >What if you want to send EOF to something on the other end of a FIFO
 >without losing the ability to send more data later?
 
 Please tell me how to "send EOF" to a pipe reader without closing 
 the FIFO...  To send more data later, you re-open it.  You re-open it 
 with the name you already know from opening it the first time.
 
 >It's all magic and you need the name of the file for the incantations.
 
 Maybe to you.  Are you really writing code that breaks if the special
 file you are addressing is re-named?  Ever heard of links?
 
 -- Andrew Shaw