Subject: Re: Checking for EOF
From: Erik Naggum <>
Date: 13 Nov 2002 00:57:12 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Duane Rettig <>
| I was responding to Marco's statement:
| | As a matter of
| | fact, the semantic I have in mind in this case is: once you have seen
| | a C-d, you have seen the EOF. Period.
| which might be read as "once my program sees an eof, it will never have to
| read from that stream again".  This would of course be disastrous, since
| if that stream happened to be terminal-like, such a program would then
| ignore data from the terminal forever.

  But this is how line-oriented terminal input is defined under Unix.  You
  can actually send an end-of-file with a C-d after a C-j or C-d, as hard an
  end-of-file as it gets.  The user has unceremoniously communicated his
  intent to terminate input to that particular process.  It would be wrong
  for that process to continue to read from that terminal stream.

  However, if you do not use the line-oriented terminal mode under Unix,
  and instead go for device-level reads, there is no end-of-file and the
  source has to signal his intent to terminate communication with that
  process through a small ceremony, like C-x C-c or some other in-band
  mechanism, or, in the case of the appropriate hardware, something like
  loss of carrier and the like.

  In other words, if you accept line mode, you accept the whole protocol.
  If you reject line mode, you also reject the whole protocol.  If you want
  a protocol, you have to implement it yourself on top of the raw stream.
  If you manage to do this, but you define some other meaning to end-of-file
  or C-d, that is of course your prerogative, but it is no longer the Unix
  line-oriented terminal protocol and should be properly identified.
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.