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

* Duane Rettig
| On the other hand, if you try typing into a terminal that is so
| connected, you would not be able to process data after the Ctrl-D, which
| is a normal action for a terminal.

  Not so.  When the C-d is not at the start of the input, it only forces
  the terminal handler to send the data collected so far to the caller.  If
  you monitor a program that calls the `read´ system call until it returns
  0 and look at what it actually does with a system-call tracer, you will
  see that you can indeed continue to type after a C-d that does not follow
  another C-d or C-j that pushed the line with the newline to the caller,
  and if the caller waits for a newline before it terminates its loop of
  `read´ calls, you should see two major effects for which this is expressly
  employed: You can write longer lines than the hard line buffer limit that
  is often only 256 characters, and you cannot edit the input line past the
  C-d.  Under any Linux system, the command `strace cat´ will do just fine.

| In other words, on a terminal, an eof is just like another character, and
| should be processed as if it were a character, including its un-read
| characteristics.

  Not in line mode.  You never see the C-d in cooked mode any more than you
  see C-r or any of the other line-editing characters.

  If you set a terminal line to raw mode so that you do see C-d and the
  like, there /is/ no out-of-band end-of-file signal, and you have to settle
  for an in-band signal, instead.

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.