Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!apple!oliveb!tymix!cirrusl!sun505!dhesi From: dhesi@sun505.UUCP (Rahul Dhesi) Newsgroups: comp.unix.wizards Subject: Re: how can I get filename from file descriptor? Message-ID: <867@cirrusl.UUCP> Date: 20 Sep 89 00:12:16 GMT References: <9353@chinet.chi.il.us> <1639@cbnewsl.ATT.COM> <10850@smoke.BRL.MIL> <14280@super.ORG> <11099@smoke.BRL.MIL> <862@cirrusl.UUCP> <11113@smoke.BRL.MIL> Sender: news@cirrusl.UUCP Reply-To: dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) Organization: Cirrus Logic Inc. Lines: 25 In article <11113@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >Out-of-band data communication is hackish. Out-of-band data communication is hackish if and only if it is designed to be so. In the limited case of an out-of-band EOF, only the representation of the EOF need be out-of-band. BSD already represents EOF correctly in most places (so one can, for example, distinguish between nothing read because of a non-blocking read finding nothing and nothing read because a blocking read found something -- such as ^D -- representing EOF). Unfortunately this mechanism is not general enough, so a process writing to a pipe has no way of communicating the same thing that a user at a tty can communicate by typing the EOF character. >There never HAS been an EOF in UNIX; it's always been a read() >returning 0. At least that is properly synchronized with the >valid data. I see no contradiction between EOF occurring and a read() returning 0 bytes. For regular files at least EOF has a very real meaning. Anywhere that you can have multiple logical files or messages on a single data stream a non-stick EOF has a very useful meaning. -- Rahul Dhesi UUCP: oliveb!cirrusl!dhesi