elmo@clarkson.edu (Paul B. Davidson) (03/13/91)
Hello, all First off, apologies if you see this twice. I've been having posting problems, and I don't think my first attempt made it offsite. The problem I have noticed is that \n and \r give "wrong" results on the console. Specifically, I have a test program that prints 80 characters, starting at col 0, and then prints a \n to force to the next line. Expected response is a continuous block of text, but the actual response is that every other line of output is blank. Carriage return (\r) has a similar misfeature, in that a solid block of text is produced, and no output is overwritten. When I looked deep into the source, and poked around with my test program, I seemed to have tracked the actual problem, although I've not found the actual bug. Essentially, when the \n or \r is output, the console first treats it as a regular character, and outputs it to the screen, which effectively rolls the current cursor pos around to the left side of the screen. Then, the special character function is performed, either moving the cursor down one line to pos 0, or simply returning the cursor to position 0. I've noticed this problem having an effect on mainframe communications using term, and occasionally with elvis's treatment of lines longer than 80 characters. The hardware I'm running minix on is a Zenith 80286 AT Clone, with 1.5M memory, and a monochrome EGA. If anyone has seen this behavior, and has solved the problem, please let me know. I'm more than willing to hack the kernel to fix it myself, but I don't want to reinvent the patch. :-) -Paul B. Davidson, elmo@sun.soe.clarkson.edu -- Paul B. Davidson, elmo@sun.soe.clarkson.edu ELMO@CLVM : BITNET ..!dumb!dumb!smart!sun.soe.clarkson.edu!elmo :Old-Style UUCP
philip@cs.vu.nl (Philip Homburg) (03/15/91)
In article <elmo.668828105@sun.soe.clarkson.edu> elmo@clarkson.edu (Paul B. Davidson) writes: %When I looked deep into the source, and poked around with my test program, I %seemed to have tracked the actual problem, although I've not found the actual %bug. Essentially, when the \n or \r is output, the console first treats it as %a regular character, and outputs it to the screen, which effectively rolls the %current cursor pos around to the left side of the screen. Then, the special %character function is performed, either moving the cursor down one line to pos %0, or simply returning the cursor to position 0. % %If anyone has seen this behavior, and has solved the problem, please let me %know. I'm more than willing to hack the kernel to fix it myself, but I don't %want to reinvent the patch. :-) I fixed it some time ago, and I think it's fixed in 1.6.xx The trick is to move some lines of code to a place just before screen is scolled or just after the screen is scolled or something like that. Philip *** ../../1.5/kernel/console.c Sat Apr 21 22:26:23 1990 --- console.c Sun Dec 9 23:51:56 1990 *************** *** 202,210 **** #if !LINEWRAP if (tp->tty_column >= LINE_WIDTH) return; /* long line */ #endif - if (tp->tty_rwords == TTY_RAM_WORDS) flush(tp); - tp->tty_ramqueue[tp->tty_rwords++]=one_con_attribute|(c&BYTE); - tp->tty_column++; /* next column */ #if LINEWRAP if (tp->tty_column >= LINE_WIDTH) { flush(tp); --- 202,207 ---- *************** *** 215,220 **** --- 212,220 ---- move_to(tp, 0, tp->tty_row); } #endif /* LINEWRAP */ + if (tp->tty_rwords == TTY_RAM_WORDS) flush(tp); + tp->tty_ramqueue[tp->tty_rwords++]=one_con_attribute|(c&BYTE); + tp->tty_column++; /* next column */ return; } }