Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon S. Allbery)
Newsgroups: comp.unix.wizards
Subject: Re: How can I read keyboard without stopping
Message-ID: <12587@ncoast.UUCP>
Date: 19 Sep 88 00:13:37 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <690@super.ORG> <1305@mcgill-vision.UUCP> <717@super.ORG>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 25

As quoted from <717@super.ORG> by rminnich@super.ORG (Ronald G Minnich):
+---------------
| In article <1305@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
| >Tty EOF-character semantics are a muddy point: is it really EOF or is
| >it just a "push", which looks like EOF when typed alone on a line?  Or
| >is it something else?  The push interpretation seems to be common.
| 
| Yeah, this was a good point, as was chris's that EOF is a transient
| thing. And it is, in many cases. And in many other cases, it is not
| (e.g. you hit the end of a pipe and the proc on the other end just died.
| You ain't goin' no where). So, it seems to me there are two types
+---------------

...unless the pipe is really a FIFO, in which case the EOF is (again)
temporary.  (That's how it seemed to work under SVR2, at least.  I would
have preferred that the call block until someone else opened the other end
of the FIFO and wrote to it, though, for the application I was trying to
write with FIFOs.  It made the program work like it was in NDELAY mode.  I
finally ended up using message queues.)

++Brandon
-- 
Brandon S. Allbery, uunet!marque!ncoast!allbery			DELPHI: ALLBERY
	    For comp.sources.misc send mail to ncoast!sources-misc
"Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI