4.2bsd eof flag in stdio

[Doug Gwyn <gwyn>]

> >Contrary to popular misconception, ^D is NOT an "EOF" character;
> >rather, it marks a delimiter for input canonicalization.
> 
> Contrary to popular misconception, neither the design of the Unix kernel nor
> its documentation was handed down on stone tablets from on high.  ...
> 
> We need a way to indicate "end of data" to a program reading TTY input.  ...

Geoff, I think you missed the point:  ^D (or whatever) from a terminal
DOES act like EOF if there is nothing between the previous delimiter
and this one, since read() will return a count of 0 on that record.
But I have made good use of the more general behavior of ^D in forcing
non-newline terminated input to the reading process.

The only reason repeated reading of an ordinary (disk) file keeps
returning 0 bytes (NOT "EOF"; there is no such thing in UNIX) is
that the file size is static.  If the file is being appended to by
some other process, then continued reading should return data AFTER
the original "end of file".  The same applies to magtape and terminals.
This is not only reasonable, it is quite useful.

I much prefer the thoughtful design of UNIX over the attempts to make
it look "safe and ordinary".

Whatever program you had that required two successive 0-length reads
("EOF" indication, by convention) to detect end of input was simply
WRONG.  (Some old-time Pascal programmers may recognize the problem.)
Instead of trying to change UNIX by reducing its generality, why not
fix the erroneous program.  There is no excuse for such sloppiness.