Re: [Gcl-devel] si::info works again on Windows

[Peter Wood]

On Fri, Mar 19, 2004 at 03:37:02PM +1000, Mike Thomas wrote:

> I believe that there is a deeper problem READ-LINE which has remained hidden
> since at least the end of 2002.
> 
> On Windows READ-LINE at the console doesn't wait for input; it just sees the
> end of the line after the (READ-LINE) and returns an empty string. I believe
> this may be CR related and I intend to look into it before Monday, time
> permitting.
> 
> If there is some text immediately after the (READ-LINE) it returns that
> text.

Hi

This has been READ-LINE's behaviour for a long time.  I have found
references to it in the KCL mailing list from 1988! :-)

It's also mentioned in the documentation (in gcl-si) ...

<start quote>  

Note that when using line at a time input under unix, input forms will
always be followed by a #\newline. Thus if you do

>(read-line) "" nil

the empty string will be returned. After lisp reads the (read-line) it
then invokes (read-line). This happens before it does anything else
and so happens before the newline character immediately following
(read-line) has been read. Thus read-line immediately encounters a
#\newline and so returns the empty string. If there had been other
characters before the #\newline it would have been different:

<end quote>

It is easy to work around, if you want to discard any chars waiting in
the input stream and just get user input you can do:

(defun rl ()
  (do ()
      ((not (listen)))
    (read-char-no-hang))
  (read-line))

I don't know if it's a bug, but it probably surprises anybody
encountering it for the first time.

Regards,
Peter