Subject: Re: Checking for EOF
From: Erik Naggum <>
Date: 11 Nov 2002 21:10:55 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Duane Rettig <>
| 1. If the stream is not a "raw" stream wrt tty processing, it might
| process a Ctrl-D as an EOF once, and then never again, unless the stream
| implementation has allowed for the "unreading" of such a "soft" eof.

  While it may appear that Unix C-d means end of file, it actually means
  "push", and acts exactly like a newline in line-oriented input mode,
  except that it does not add itself to the end of the input.  Many Unix
  users are tremendously puzzled by this because they have learned that C-d
  means end-of-file in Unix and therefore fail to understand why they need
  /two/ C-d's when they want to end input at any other place than after a
  newline character.  E.g., if you want to stuff a some text into the X
  selection, you must use

$ xsel -i
[whatever] <C-d> <C-d>

  because the final newline that would be entered with C-j C-d is highly
  undesirable.  The first C-d pushes the input collected so far to the
  reading process, so the `read´ system call returns "[whatever]" and 10.
  The next `read´ system call returns "" and 0, and /this/ is the clue that
  input has ended.

  I have held many Unix courses over the years, and in every single one,
  the majority of the attendants, even in courses for for experienced C
  programmers and system admins, have believed C-d to be the Unix end of
  file "character".  I have found it very useful to teach people about line
  input processing in general.  Most Unix users are completely clueless
  about this fundamental aspect of their interaction with the system.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.