For background, I'm trying to fix a bug in my embedded linux system. I'm using Minicom in Ubuntu to access the device's console via serial UART. When entering a long command, after 80 characters total (including the prompt) the cursor will jump to the beginning of the same line and overwrite the prompt and what I've already entered, rather than jump to the next line The buffer is preserved and the command will execute fine, but the text that's displayed is overwritten.

For example:

$ cat "xxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1" > thisisatest.txt

Will look like:

thisisatest.txtxxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1xxxxxxxx1" >

I've asked this before, and some have suggested that it's a mismatch between the terminal emulators, but my embedded and system and Minicom are both set to use vt102. And this issue occurs with any Windows terminal applications as well. I don't see the problem when logging into the embedded system via telnet.

Theories are very welcome, but I'm mainly asking for information on how what you type is displayed on the command-line as you're typing. Suggestions for where to look in the source would work, too. I don't know if this is handled by the shell (Bash, in this case), or at a lower level by the kernel (maybe stdin is directed to stdout by default somehow), or at the hardware level as a serial device thing. So I'm not sure where to look.

I've read material on standard I/O, but I've only been able to find stuff on how the shell executes commands after you hit ENTER. But nothing about how the text is displayed before you hit ENTER.

"By default, minicom will not wrap longs lines of text, which causes them to run off the edge of your terminal screen. To avoid this, use the '-w' command line option. See 'man minicom' for more information. "

The above quote is from http://elinux.org/Minicom

Was this helpful?

Thanks for the reply. It's not a problem with Minicom as it readily displays kernel stdout to the full width of the window and other Windows terminal applications (e.g. TeraTerm, SecureCRT, Hyperterm) behave the same way. So it must be the embedded device. This problem is exclusive to entering commands before you hit ENTER, and nowhere else. It's very strange. I keep thinking it has to do with stdin, but the 80 character limit before the wrap includes my "# " prompt which doesn't come from the keyboard.

Anyone? Maybe it sounded like I was asking someone to solve my problem. I'm really just asking for a pointer to where to look in the source or online for how what you're typing gets to the screen.