Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.wizards
Subject: Re: how can I get filename from file descriptor?
Message-ID: <9353@chinet.chi.il.us>
Date: 25 Aug 89 03:43:51 GMT
References: <9340@chinet.chi.il.us> <1607@cbnewsl.ATT.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Public Access Unix
Lines: 49

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.

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

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?  What if you want to
do a verify pass on a tape device where the only way to rewind is
to close() and open()?  What if you need to twiddle the handshake
lines on a tty device?  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?  It's all magic and you need the name of the file for
the incantations.

Les Mikesell