Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: pty bugs & features
Message-ID: <3999@auspex.auspex.com>
Date: 2 Sep 90 01:16:42 GMT
References: <6038@muffin.cme.nist.gov> <13650@smoke.BRL.MIL> <1990Aug29.153306.18173@chinet.chi.il.us>
Organization: Auspex Systems, Santa Clara
Lines: 25

>Is this meant to imply that the developers of STREAMS don't understand
>unix?

Given that the S5R4 pty driver, at least, returns 0 on the master side
when the slave side is closed, and that it's the *BSD* pseudo-tty driver
that behaves in the fashion Doug is complaining about, I don't think
that's what he meant to imply...

>A read on a STREAMS file is documented to return -1 when O_NDELAY
>is set and there is no data available

...and since that's not a case of a "normal EOF", it's not what you
should be inferring, either.

>(which has unfortunately been propagated into the tty emulation of at
>least some network implimentations).

Prior to S5R3.2 or so, there was no way for a streams device to indicate
that O_NDELAY should behave in the old tty driver fashion.  We (Sun) added a
mechanism (basically S5R3.2-compatible) to the SunOS 4.0 streams code
which was S5R3.1-based, because we knew this was a compatibility
problem; apparently, the implementors of said tty emulations weren't as
aware of this as we were.  One hopes the S5R3.2-based versions of those
tty emulations are polite enough to request old-style behavior from the
stream head....