4.2bsd eof flag in stdio

[Geoff Kuenning]

>Contrary to popular misconception, ^D is NOT an "EOF" character;
>rather, it marks a delimiter for input canonicalization.  If all
>previous input has been consumed and a ^D is typed, then read()
>returns a count of 0.  This is often interpreted as EOF.  If there
>is some uncanonicalized input and ^D is typed, it acts much like
>NEWLINE except of course no \n is appended.

	-Doug Gwyn

Contrary to popular misconception, neither the design of the Unix kernel nor
its documentation was handed down on stone tablets from on high.  I don't
really care whether Thompson and Ritchie chose to describe the behavior of
the original Unix TTY driver as "EOF" or "canonicalization".  I strongly
suspect that their motivation was to describe the behavior of the code they
actually wrote, and the code was written for convenient implementation.

We need a way to indicate "end of data" to a program reading TTY input.  It is
convenient for programmers to consider "end of file" as "end of data" when
reading file input.  Since redirection of stdin is one of Unix's great
features, it is thus reasonable to simply provide a way for a TTY to indicate
"end of file".  If T&R implemented it sloppily and documented it accurately,
that is no reason for us to slavishly follow their lead.

Once you decide to have ^D truly mean "end of file", it is only reasonable
to make it operate like a true EOF.  That means that multiple reads return
multiple EOF indications, just like a disk.  The original implementation
can be extremely disconcerting--I had a program a few days ago that wanted
two EOF's to terminate.  It tested fine from a file, but "hung" when I
typed in the input and terminated it with ^D.

 The fact that some programs have in the past misinterpreted this bug as a
 feature and made use of it is unfortunate, but something we will have to
 live with.  It is just not that hard to grep for "EOF" and add "clearerr"
 calls.  In any case, any program that was doing this was already providing
 incompatible behavior between files and TTY's.  That's what you get when
 you special-case TTY input :-).
-- 

	Geoff Kuenning
	First Systems Corporation
	...!ihnp4!trwrb!desint!geoff