Nathan Baum <nathan_baum@btinternet.com> wrote:
+---------------
| I _expect_ ^D to be interpreted as an EOF character in any line-based
| program.
+---------------

Then you do not understand how Unix-based terminal drivers work!!
As other have noted, the "EOF" character (^D or otherwise) is
*just* a "push" which completes a blocking "read()", and nothing else.
All of the "EOF" semantics occur because an EOF character typed
on an empty line [and *ONLY* and *empty* line!] causes a "push"
with no characters read yet, and thus "read()" returns zero, and
the Unix/Linux/POSIX convention is that "read()" returning zero
means "EOF".

"Any line-based program" never *sees* the EOF character -- it
*only* sees "read()" returning zero. And if you type "abc^D",
the read returns 3. As it should. As it has since 1971!!

+---------------
| CMUCL irritates me by not allowing me to enter ^D on a fresh
| line and just quit.
+---------------

Ahhh... *That's* a horse of a different color.  ;-}  ;-}
You mean the annoying:

    cmu> Received EOF on *standard-input*, switching to *terminal-io*.
    cmu> 
    Received EOF.
    cmu> 
    Received EOF.
    cmu> 
    Received EOF.
    cmu> 
    ...[and so on, once for every *two* ^D's typed, up to 10 pairs]...

You can fix that with a (SETF *BATCH-MODE* T) in your "~/.cmucl-init"
file [*not* on the command line, though, it'll do other nasty stuff
to you in that case, like exit on any unhandled condition instead of
entering the debugger]. Yes, it still takes *two* ^D's [why? I dunno],
but at least it exits quietly in that case:

    $ cmucl
    ...[chatter]...
    cmu> (setf *batch-mode* t)

    T
    cmu> $ 
	|
	+--- Two ^D's typed here.


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607