pty bugs & features

[Don Libes]

In article <3948 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>>The Dec behavior is what I would've expected.  The Sun engineer could
>>not explain where the number 15 came from,
>
>It comes from the AT&T S5R3.x source code.  Where it got the number, I
>don't know.

Uhhh, this wasn't quite the answer I was looking for.  Let me rephrase
the question(s):

Why do pty's return EIO instead of 0 upon EOF?
Is SunOS, Ultrix, or neither doing the "right" thing?
If Ultrix is BSD-based and SunOS is SV-based, obviously this EIO
behavior is common practice, yet I don't find any documentation on it,
nor could a company engineer explain it.  What's the rationale?

Why do stream's dump their buffers when the writer closes?  I would
think this could be a problem with other drivers besides ptys.  Or am
I confused and is this just an error in the way the pty driver uses
streams?  Is it possible to change this behavior using a flow control
option without taking a severe hit in efficiency?  (The manual alluded
to this but didn't give enough to go on.)

What is it you are expected to do in 15 seconds?  It sure seems
unusually large for internal system cleanup purposes.  Yet it is
worthless for user purposes if you can't make it infinite.  Why can't
you change this number?

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.  (This is a rhetorical question at the moment since the FAQ
has slipped off the face of the earth.  Hey, repost that sucker!)

Don Libes          libes at cme.nist.gov      ...!uunet!cme-durer!libes