Path: utzoo!attcan!uunet!husc6!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: How can I read keyboard without stopping
Keywords: curses keyboard
Message-ID: <1305@mcgill-vision.UUCP>
Date: 11 Sep 88 10:19:13 GMT
References: <813@ms3.UUCP> <1246@mcgill-vision.UUCP> <669@super.ORG> <690@super.ORG>
Organization: McGill University, Montreal
Lines: 37

In article <690@super.ORG>, rminnich@super.ORG (Ronald G Minnich) writes:
> If you are reading a regular file, and someone else is writing, then
> there are times when your current seek offset will match the returned
> size.  You are still not at eof, as someone else has the file open.

Sure you are.  Just because it might not be EOF a minute from now
doesn't make it any less truly EOF right now.  (Just because someone
else has the file open makes no difference.  Someone could open it and
append something else even if nobody has it open just now.)

> tail -f, tail never really does know when it hits eof- you, peculiar
> creature that you are, decide for it via ^C :-).

Tail hits EOF just fine.  The -f option tells it that when it does hit
EOF, it's to sleep a little and check again to see whether EOF is still
in the same place it used to be - and if not, to read the new data and
print it out.

> P.S. Does it strike anyone as strange that stdio and level 2 have
> such different ideas about eof? Level 2 you can just read right
> through ^D;

Tty EOF-character semantics are a muddy point: is it really EOF or is
it just a "push", which looks like EOF when typed alone on a line?  Or
is it something else?  The push interpretation seems to be common.

> for standard IO, one is enough; you lose it all right there.  The
> FILE * gets closed for you.

Not in any stdio I've ever heard of!  You must fclose() the stream if
you want it closed.  What if it's a read/write stream and the program
wants to rewind() and rewrite the file?

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu