Wanna see a fun bug? Try this: echo -n blahblahblahblahblah
Now type off the right edge of your terminal, and then hit backspace to try to go back up. The problem is that ash assumes that its shell prompt always starts at the left edge of the screen, then adds the length of the prompt it prints to figure out where the cursor is. If you didn't start at the left edge of the screen, this doesn't work. The reason it needs to keep track of this is that unix terminals suck. Specifically, backspace won't automatically back you up to the previous line, the only way to do multiline interactive editing is to keep track of your current cursor position and compare it to the width of your screen (which you also have to know) in order know when to cursor _up_ and jump to the right edge of the screen. However, if your shell prompt didn't start at the left edge of the screen (which happens surprisingly often), the resulting line editing is completely horked once you go past the right edge of the screen. (Command history becomes a lot less fun to use, too.) It's easy enough to fix once you know what the problem is and decide to address it. We just haven't yet... Rob P.S. While we're at it: when the shell is in interactive mode and CONFIG_FEATURE_EDITING is enabled but we can't query the current tty size, and either $COLUMNS and LINES$ are blank, then what we should probably do right before printing each prompt is some variant of: echo -e "\e[s\e[999C\e[999B\e[6n\e[u" That should trigger your ansi-compliant console to send back: \e[LINES;COLUMNSR Where LINES is decimal number of lines, and COLUMNS is the decimal number of columns. So you'd then want to teach your ansi escape sequence parsing logic (the stuff currently handling cursor up/down/left/right and so on) to understand esc[YY;XXR escapes and use them to set $LINES and $COLUMNS respectively. Note you probably only want to send that escape sequence if there _isn't_ already input pending. (Has the escape sequence parsing logic I tweaked in the VI code last year been genericized yet?) The reason to do this is it'll drill through to your xterm even through a serial console, and return the width and height of the console even when the remote system busybox has NO clue what your console size is because that information lives on a separate computer. The shell could then set LINES and COLUMNS based on that for the next command it runs, although it should remember that they weren't set when the shell was originally run so it shouldn't trust those values, and should probably re-query it every prompt in that case because we don't get WINCH signals through a serial console either... Anyway, just a thought. :) Still Rob. -- Latency is more important than throughput. It's that simple. - Linus Torvalds _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
