Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.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: <11119@smoke.BRL.MIL>
Date: 20 Sep 89 15:22:51 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>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 60

In article <867@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
>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.

Not according to me!

>In the limited case of an out-of-band EOF, only the
>representation of the EOF need be out-of-band.

But since it could readily be in-band, out-of-band representation
is hackish.

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

^D does NOT NOT NOT represent EOF.  It delimits the input without
being inserted as a character in the input stream, unlike newline.
Verious UNIX terminal handlers have implemented this differently,
but in general if you type ABC^DEFG^J the first read gets ABC and
the next read gets EFG^J.  If ^D is the first input immediately
after a preceding delimiter (^D or newline), then the read gets 0
bytes returned, WHICH IS CONVENTIONALLY INTERPRETED as meaning
"end of file".  UNIX, as I said, has no inherent notion of EOF.

>Unfortunately this [BSD]  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.

I agree that BSD doesn't do it right.  I'm told that SVR4 stream
pipes will probably support 0-length packets correctly.

Data packet length is a fundamental notion.  Both the OS file-system
code and common applications such as the "cat" utility should preserve
this attribute.  It's a "free" side effect of the UNIX generalized
notion of "file", if implemented properly.  No special kludges are
required.

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

It merely means that there is no data currently available past the
current seek pointer position.  A subsequent read() attempt may in
fact succeed.

I don't know what contradiction you're talking about.

>Anywhere that you can have multiple logical files or messages on a
>single data stream a non-stick EOF has a very useful meaning.

Of course it does!  It's exactly because it's meaningful and useful
to have a 0-length datum that I get annoyed when it's not properly
implemented.