Subject: Re: Checking for EOF From: Erik Naggum <firstname.lastname@example.org> Date: 13 Nov 2002 00:57:12 +0000 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Duane Rettig <firstname.lastname@example.org> | 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.