Subject: Re: Checking for EOF
From: Erik Naggum <erik@naggum.no>
Date: 11 Nov 2002 22:29:28 +0000
Newsgroups: comp.lang.lisp
Message-ID: <3246042568510031@naggum.no>
* 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.