readline() sends a \n when it got a \r
authorBarret Rhoden <brho@cs.berkeley.edu>
Tue, 16 Aug 2011 00:12:26 +0000 (17:12 -0700)
committerKevin Klues <klueska@cs.berkeley.edu>
Thu, 3 Nov 2011 00:36:06 +0000 (17:36 -0700)
We tend to treat \n as \r, like in a printk().  Similarly, we treat lone
\rs as \ns.  The serial port actually sends just \rs, not \r\n.
Basically, we treat \r and \n similarly.  When writing to the serial
port, they are the same.  When writing to the monitor, \n does a \r too,
but you can do a \r alone.

It's all rather ugly.  One way (a long-term better way) to deal with
this would be to make \n and \r do what they are supposed to do at the
device level, and change printk() to add \rs to its \ns.

Things would be a little nicer if minicom would send a \n.

kern/src/readline.c

index 77c71c5..4ced81d 100644 (file)
@@ -36,8 +36,10 @@ int readline(char *buf, size_t buf_l, const char *prompt, ...)
                                cputchar(c);
                        i--;
                } else if (c == '\n' || c == '\r') {
+                       /* sending a \n regardless, since the serial port gives us a \r for
+                        * carriage returns. */
                        if (echoing)
-                               cputchar(c);
+                               cputchar('\n');
                        assert(i <= buf_l - 1); /* never write to buf_l - 1 til the end */
                        buf[i++] = c;
                        retval =  i;