Xref: utzoo comp.lang.c:13599 comp.unix.questions:9938
Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uwmcsd1!marque!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.questions
Subject: Re: input ready under UNIX ??!!??
Keywords: input, unix, help
Message-ID: <320@auspex.UUCP>
Date: 27 Oct 88 19:49:49 GMT
References: <771@necis.UUCP> <547@poseidon.ATT.COM>
Reply-To: guy@auspex.UUCP (Guy Harris)
Followup-To: comp.unix.questions
Organization: Auspex Systems, Santa Clara
Lines: 39

>(1)  Using fcntl(2), set file descriptor 0 to be non-blocking (what
>fcntl(5) calls O_NDELAY).  If you want line-at-a-time input, keep
>canonical processing on.  read() will return a positive value if a
>line has been entered.  If a line hasn't been entered yet, read() will
>either return 0 (SVR2?), or -1 with errno set to EAGAIN (SVR3?).

SVR3 *only* if you have a streams-based tty, and I think most, if no
all, are not streams-based.  Even there, they may have changed it so
that even streams-based ttys return 0 (SunOS 4.0 does The Right Thing on
streams-based ttys - it had better, since it doesn't support
non-streams-based ttys - which means returning 0 for S5-style
non-blocking I/O and -1 with "errno" set to EWOULDBLOCK for 4.2BSD-style
non-blocking I/O). 

The guy said ICANON, so I'll assume that if he's working on a system
with both BSD and S5 environments he's working in the S5 environment;
this means the bottom line is "'read()' will return 0 if no data has
been entered yet."

Unfortunately, if you are in canonical mode, this is indistinguishable
from end-of-file, so you may have a real problem here, and you may want
to turn ICANON off and, if you need canonical processing, do it
yourself.  (Most programs that do this sort of thing run in
non-canonical mode anyway....)

POSIX fixes this by adopting a convention similar to the BSD one; a
"read()" when no data is available returns -1 and sets "errno" to
EAGAIN.  You use O_NONBLOCK for this, rather than O_NDELAY, so as not to
break old programs.  I don't know what systems out there have
implemented this yet.

>(If you're paranoid that the child might die, dup(2)
>file descriptor zero, close(2) file descriptor zero, dup() the copy
>(which will become file descriptor zero), and close() the copy.  The
>child process now has its own file descriptor for standard input.)

This doesn't help.  No-delay mode is a property of the "file table
entry", not of the "file descriptor", so if you "dup" a file descriptor
both the original and the "dup"ed copy share no-delay mode.