[Mono-bugs] [Bug 81159][Nor] Changed - Console.In.Read doesn't allow line-oriented input with mscorlib 2.0

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by gert.driesen at pandora.be.

http://bugzilla.ximian.com/show_bug.cgi?id=81159

--- shadow/81159	2007-04-18 13:17:03.000000000 -0400
+++ shadow/81159.tmp.25091	2007-04-18 13:58:39.000000000 -0400
@@ -99,6 +99,35 @@
 Created an attachment (id=19083)
 81159.patch
 
 
 ------- Additional Comments From fejj at novell.com  2007-04-18 13:17 -------
 does this patch resolve the issue?
+
+------- Additional Comments From gert.driesen at pandora.be  2007-04-18 13:58 -------
+No, it doesn't:
+
+I still get the same behavior on the 1.0 profile. The behavior of 
+the 2.0 profile did change but does not match MS.
+
+With your patch, only the first 16 characters are echoed back during 
+the first read (while they are all echoed on MS).
+
+Then, after hitting the enter key the characters that were entered 
+after these 16 characters are echoed at the location where the 
+second read is performed. On MS only the keys that were entered 
+after the second read are echoed there, but the returned line does 
+include the characters that were echoed but not read during the 
+first read.
+
+Also, on Mono the second read immediately finishes while on MS it 
+wait until the user presses enter.
+
+Note: pressing enter on Windows (atleast on MS) causes CR+LF (13 10) 
+to be written to the console, so checking for \n will not work. I 
+think you should use Environment.NewLine (and cope with the fact 
+that I has only one character on Linux and 2 on Windows).
+
+I also noticed that on Mono 2.0 profile the backspace is also 
+counted as a character while this works fine on the 1.0 profile. But 
+I'll probably submit a separate bug report for that once this one's 
+fixed.