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