[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


    Date: Mon, 01 Aug 88 13:17:32 -0700
    From: ssmith@ruffles.nrtc.northrop.com (Stephen P. Smith)

    Has anyone noticed the erroneous behavior with the EOF processing
    of READ-CHAR-NO-HANG?  It is *supposed* to behave differently than
    LISTEN by returning a NIL if no character is available but
    distinguishing an EOF with either an error or returning an EOF-VALUE.
    However, it does not appear to work, as can be seen by evaling
    the following (in 7.1 and 7.2):

    (with-open-file (stream "AnyRandomTextFile" :direction :input)
       (loop for thing = (read-char-no-hang stream nil :eof)
	     until (equal thing :eof)
	     when (characterp thing)
	       do (format t "~c" thing)
	      else do
		  (format t "~%Got ~s." thing)))

    which shows that READ-CHAR-NO-HANG begins to return NIL after the
    end-of-file is hit. 

    Since this doesn't work, is there any other method to LISTEN on
    a collection of streams (which can be files, windows, network links)
    returning the ones that have characters available and/or have
    gone to EOF.

    --Steve Smith

Well, there is PEEK-CHAR.  But you should be aware that there are some
unfortunate potential interactions between input editing context(s)
(which are often nested and inherit) and untyi, which gets called if you
use PEEK-CHAR and friends.  In particular, if you have a :do-not-echo
option somewhere in an enclosing input editing context, you're likely to
get an error of approximately the form "Attempt to untyi <foo>, which
was not the last character read."  (This is not the exact text of the
error message, but you get the idea.)