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

* Duane Rettig <duane@franz.com>
| 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.