Thanks, YC. I will give this a try. Note, however, that if I found this confusing, others will too. This is a difference in behavior from running under DrScheme and MzScheme. I would recommend that it be documented somewhere. -- Eric<br> <br><div class="gmail_quote">On Fri, Oct 2, 2009 at 11:50 AM, YC <span dir="ltr"><<a href="mailto:yinso.chen@gmail.com">yinso.chen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br><br><div class="gmail_quote"><div class="im">On Fri, Oct 2, 2009 at 9:23 AM, Eric Swenson <span dir="ltr"><<a href="mailto:eric@swenson.org" target="_blank">eric@swenson.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> <br><br><div class="gmail_quote">On Fri, Oct 2, 2009 at 9:21 AM, Eric Swenson <span dir="ltr"><<a href="mailto:eric@swenson.org" target="_blank">eric@swenson.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex"> Hello Chongkai,<div><br></div><div>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"? </div> <div></div></blockquote></div></blockquote></div><div><br>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 "").<br> <br>Use (read-line (current-port) <b>'any</b>) instead of just plain (read-line) will treat \r\n as a single terminator.<br><br>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. <br> <br>(define (my-read-line) <br> (read-line (current-input-port) 'any)<br> (read-line (current-input-port) 'any)) <br><br>Since this specifically tackles the behavior of REPL - it has limited applicability elsewhere.<br> <br>Cheers,<br>yc<br><br></div></div> </blockquote></div><br>