>* if neither $LINES/$COLUMNS are set nor ioctl(TIOCGWINSZ) > returns useful data, print > ESC"7" ESC"[r" ESC"[9999;9999H" ESC"[6n" ESC"8" > in order to retrieve terminal's size, and whenever read_key > does detect that, use this info for proper linewrapping > in line editing.
TERM should be consulted somehow, so that it concludes an ANSI escape sequence is the correct thing to do. Don't know what, if anything, BB's got in that line. >Sure, the "wall" program...will screw >up your display. So what? So you need a way to recover the view of the line you're currently editing _anyway_. Given this, it can _also_ be used to recover from the weird "echo -n" scenario under discussion, or anything else odd. No blotted output, no vast sweeping changes of code, no dependence on bug-free full VT emulation, etc. No vulnerability to interleaved user input and automated response sequences. Just a simple user reaction to an exceptional condition, no muss, no fuss. Something look odd? Just call for a repaint and see where you are. >Which says vt100 actually _does_ support the esc[6n "Get cursor position" >sequence. Real VT's do, but this is one of the areas where various terminal emulation software can fall down easily. BTDT. Make it too tricky and you're opening the door for unhappy users. Unless you're into forced upgrading of associated SW just for the fun of it. (Ala MSoft. Is Linux the new DOS?) I'm talking about _less_ work for an entirely acceptable solution, that's all. One that was generally accepted for decades, with untold thousands of satisfied users. One with more likelihood of working in more situations and with more varied terminal clients, even over very slow satellite links. What's not to like? -- Jim _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
