Subject: Re: Checking for EOF From: Erik Naggum <erik@naggum.no> Date: 11 Nov 2002 21:10:55 +0000 Newsgroups: comp.lang.lisp Message-ID: <3246037855355521@naggum.no> * Duane Rettig <duane@franz.com> | 1. If the stream is not a "raw" stream wrt tty processing, it might | process a Ctrl-D as an EOF once, and then never again, unless the stream | implementation has allowed for the "unreading" of such a "soft" eof. While it may appear that Unix C-d means end of file, it actually means "push", and acts exactly like a newline in line-oriented input mode, except that it does not add itself to the end of the input. Many Unix users are tremendously puzzled by this because they have learned that C-d means end-of-file in Unix and therefore fail to understand why they need /two/ C-d's when they want to end input at any other place than after a newline character. E.g., if you want to stuff a some text into the X selection, you must use $ xsel -i [whatever] <C-d> <C-d> because the final newline that would be entered with C-j C-d is highly undesirable. The first C-d pushes the input collected so far to the reading process, so the `read´ system call returns "[whatever]" and 10. The next `read´ system call returns "" and 0, and /this/ is the clue that input has ended. I have held many Unix courses over the years, and in every single one, the majority of the attendants, even in courses for for experienced C programmers and system admins, have believed C-d to be the Unix end of file "character". I have found it very useful to teach people about line input processing in general. Most Unix users are completely clueless about this fundamental aspect of their interaction with the system. -- 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.