[plt-scheme] MzScheme and read-line

From: YC (yinso.chen at gmail.com)
Date: Fri Oct 2 14:50:13 EDT 2009

On Fri, Oct 2, 2009 at 9:23 AM, Eric Swenson <eric at swenson.org> wrote:

> On Fri, Oct 2, 2009 at 9:21 AM, Eric Swenson <eric at swenson.org> wrote:
>> Hello Chongkai,
>> Thanks for your suggestions.  I tried this, but it didn't work.  In the
>> case where (read-line) is returning "\r", I note that read-bytes-avail!* is
>> returning 0, yet a subsequent read-line still returns "\r".  (I tried your
>> example code exactly, and my-read-line returns "\r" as well.)  I wonder if
>> this is a Win32 issue (line-ending issue) where some of the win32-specific
>> support is not stripping the "\r" from the end-of-line sequence "\n\r"?
The line ending on Windows is \r\n instead of \n\r.  The reason you have \r
returned is because (read-line) as is by default only use \n as a
terminator, so when it sees \r\n it thinks \r is the data and returns it (on
Unix it only sees \n, so the data is "").

Use (read-line (current-port) *'any*) instead of just plain (read-line) will
treat \r\n as a single terminator.

As Chongkai said - when you type (read-line)<enter> the reader will consume
the (read-line) but leaves <enter> in the buffer, which read-line then
consumes, so you need a function that has two read-line calls, the first
will consume the left over, and the second will then wait on input.

(define (my-read-line)
  (read-line (current-input-port) 'any)
  (read-line (current-input-port) 'any))

Since this specifically tackles the behavior of REPL - it has limited
applicability elsewhere.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20091002/50c8cd1a/attachment.html>

Posted on the users mailing list.