Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.bugs.4bsd
Subject: Re: read() from tty has fencepost error
Message-ID: <6040@brl-smoke.ARPA>
Date: Tue, 30-Jun-87 12:07:14 EDT
Article-I.D.: brl-smok.6040
Posted: Tue Jun 30 12:07:14 1987
Date-Received: Fri, 3-Jul-87 07:25:46 EDT
References: <648@haddock.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: world
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 12

In article <648@haddock.UUCP> karl@haddock.isc.com (Karl Heuer) writes:
>If you type *exactly* 5 characters and terminate the read with EOT (which is
>not an EOF in this context, in the middle of a line), the first read returns 5
>(as it should) and the second returns 0 (instead of waiting for more input).

That is correct behavior.  In cooked mode, the "EOT" character is a delimiter
that is inserted into the stream along with the others.  It is NEVER an "end
of file" character; that is merely a conventional interpretation given to a
delimiter found as the first character of a text line.  Your first read got 5
characters, and the second read encountered the delimiter, which stops input
and returns the number of characters found before the delimiter (0 in this
case).