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.