I've noticed since I installed gentoo (possibly with other distributions, but I at least didn't ever notice until Gentoo) that bash acts flakey with terminals sometimes. For example, excessively long (multi-line) command lines. Sometimes bash will go to the beginning of the current line, and start putting stuff there, instead of to a new line. Also, sometimes when hitting the up arrow with long (or even just 2 character, like fg) command lines in the buffer, bash steps up a line. Often this makes it VERY difficult for me to competantly up-arrow page through my command history. Some things to try: 1. Do commands that wrap multiple lines, like try emerging directly from ebuilds for 3-5 ebuilds. 2. Use vim and less a lot. 3. Do things inside a gnome terminal, especially, spawn multiple tabs and then resize the window. Things to watch for: 1. Does the cursor suddenly go to the beginning of the line, rather than to the next line? 2. Does hitting the up arrow move the prompt up a line? 3. Does hitting the DOWN arrow also move the prompt up a line? 4. Does inserting or deleting characters from the beginning or end of the line cause the prompt to move up a line? These happen to me most often in a gnome terminal, but I've seen it happen on text consoles as well. Perhaps bash has a slight memory leak?
I've had this problem often, but I'm not sure exactly what is to blame. BTW, I usually use aterm (an rxvt variant). I often have these problems when I start a full terminal program like nano or less, then resize the terminal, then exit. The fullscreen app usually handles the change, but Bash doesn't. The COLUMNS and LINES variables haven't been updated and there are the readline problems you describe. What do you usually do that triggers your problems? In my case, it may be that the shell doesn't get updates from the terminal while the fullscreen app is running, so there is no way it can know of the size change. Another thing to be aware of is that Bash needs to know about any non-printing characters in your PS1 variable which determines the prompt. If you don't surround any escape codes that change colors and such with "\[" and "\]", Bash will think the prompt is longer than it appears in the terminal, which could also cause readline problems.
This isn't a bug. Bash isn't a fullscreen program like vim or nano, so it isn't using ncurses or slang to draw. Instead it's using simple terminal escape codes (via readline) to draw starting wherever the cursor is, which is usually the start of a new line. If the size of the terminal changes, then bash needs to be notified of the change. Here are some things that can help: 1. When you resize the terminal while running another program, sometimes bash needs to be told about it when you exit. Run "resize" (part of the X distribution) to pick up the new terminal size. 2. In your .bashrc, include the following line to make bash check the size of the terminal every time before it prompts: shopt -s checkwinsize 3. Make sure, as was mentioned in comment 1, that any escape sequences in your prompt which don't change the cursor position are surrounded in \[ and \]. There is more information about this in the bash man-page. If you use the Gentoo default prompt, then this is already done. 4. When all else fails, you can "exec bash" which will cause bash to restart. This shouldn't be necessary, but every once in a while I find that "resize" followed by "exec bash" does the trick. Hope that helps.
just to add something more ... if you launch bash, launch another interactive app (nano/less/etc...), resize the window, close the app and get back to the shell, your prompt will be 'screwed up' ... thats because the signal that was sent to indicate a change in window size was handled by the foremost app and not bash, thus bash still thinks the window size is the same as before you launched the app ... another 'quick fix' is to just resize your terminal slightly while bash is the active process aron: a possible idea is to add the checkwinsize to the default .bashrc in the /etc/skel/.bashrc file ?
My gut feeling is that I'd rather not do that since it's not the bash default. *shrug*
