Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: how can I get filename from file descriptor?
Message-ID: <11236@smoke.BRL.MIL>
Date: 7 Oct 89 00:40:59 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> <867@cirrusl.UUCP> <1189@necisa.ho.necisa.oz> <947@cirrusl.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 28

In article <947@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>In article <1189@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts)
>writes:
>>There is no EOF in UNIX; ...
>>...A suitable stream line discipline would solve 
>>whatever your problem is.
>There *is* an EOF in UNIX.  Enough UNIX documentation says it that I
>believe it.  Case closed.

UNIX beginner's documentation talks in terms of EOF to keep the notion
simpler for the novice.  However, Boyd is right; there is no EOF in UNIX.
There is a 0 return from read(), which is often INTERPRETED as meaning
EOF.

>The zero-length read/write strategy, besides not working for pipes,
>also doesn't work with buffered streams.  It's a pretty poor solution
>at this time.

0 return from read() always works.  The problem is that many common
implementations do not creat a 0-length packet when you write() 0 bytes.
Thus it is IMPOSSIBLE to "read EOF" more than once from a pipe on such a
system.  There have been implementations that support writing 0-length
packets.  That's effectively what most UNIX terminal drivers do when
the "EOF" character (typically ctrl-D) is entered immediately after a
preceding delimiter ("EOF" or "newline").

The fact is, there are some pretty poor implementations of UNIX in
widespread use..