Subject: Re: (warn) isn't doing what I expect it to
From: (Rob Warnock)
Date: Fri, 02 Sep 2005 03:29:03 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Nathan Baum <> 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*.
    Received EOF.
    Received EOF.
    Received EOF.
    ...[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
    cmu> (setf *batch-mode* t)

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


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607