Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mephisto!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: pty bugs & features
Message-ID: <13650@smoke.BRL.MIL>
Date: 27 Aug 90 05:29:06 GMT
References: <5992@muffin.cme.nist.gov> <3948@auspex.auspex.com> <6038@muffin.cme.nist.gov>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 37

In article <6038@muffin.cme.nist.gov> libes@cme.nist.gov (Don Libes) writes:
>Why do pty's return EIO instead of 0 upon EOF?

If they do this, it is clearly wrong and would most likely be due to
UNIX development now being done, or at least directed, by people who
don't understand UNIX.  read() should not return -1 upon encountering
normal EOF on ANY object.  If the end of the stream is due to a
communication link failure, for example, then an error indication
would in fact be preferable to an undifferentiated EOF indication.

>Why do stream's dump their buffers when the writer closes?

They're not supposed to; do they really do that?  Is USO really
screwing up UNIX to such an extent??

>What is it you are expected to do in 15 seconds?

There is no justification for penalizing an application for not
consuming all the data buffered in the kernel within 15 seconds.

I lost track of the origin of this thread; if this timeout is supposed
to be related to the TCP protocol, my guess would be that somebody has
yet again tripped up on the "FIN_WAIT_2" issue.

>And finally, why does everyone answer easy questions with "[long essay
>deleted] and this should probably be in the FAQ if it isn't already"?
>That indicates to me that neither the asker nor the answerer has read
>the FAQ.

Not really, usually it indicates that the responder has not memorized
the FAQ list but feels that the question should be there and that either
the asker has failed to read the FAQ list or else the question wasn't
there.  (Or, as in in your case,

>... at the moment ... the FAQ has slipped off the face of the earth.

)