If you have escape sequences in a bash prompt, and execute several long commands (longer than one line) so that they are in the history buffer, and then press cursor-up and cursor-down to change between these commands, the prompt may be messed up and the displayed command lines too. Fix: Do not have escape sequences in the prompt. How-To-Repeat: I assume you are in a bash shell (port shells/bash2), in a cons50 terminal with 80 columns. a) Get a prompt with escape sequences: export PS1='\[\e[7m\]hello\[\e[m\]' b) Get suitable command into the history: ab ab ab ab ab ab ... ab (That is so many 'ab' groups that the last 'b' is in the second row exactly under the first 'l' of the prompt) c) Get second command so you've got something to change: cd cd cd cd cd cd ... cd (Make it the same length, so the last 'd' is also below the first 'l' of the prompt) d) Press cursor-up and cursor-down so you change between these two commands in bash's history. Watch the prompt.
bdluevel@heitec.net wrote: > If you have escape sequences in a bash prompt, and execute > several long commands (longer than one line) so that they > are in the history buffer, and then press cursor-up and > cursor-down to change between these commands, the prompt > may be messed up and the displayed command lines too. If you are not already, please try Bash 2.04. There were several improvements in ANSI escape sequence handling. If you are having additional problems after upgrading, please use bash-bug to report them. This is a Bash problem, not a FreeBSD one. Good luck, Doug
Doug Barton wrote: [...] > If you are not already, please try Bash 2.04. There were several > improvements in ANSI escape sequence handling. If you are having > additional problems after upgrading, please use bash-bug to report them. > This is a Bash problem, not a FreeBSD one. [...] I was indeed using Bash 2.03. I have now updated to 2.04 and the problem has not changed. The same effect happens on NetBSD 1.4.2 (bash 2.03 there); so, unless they have the same curses-or-whatever bug, it's indeed a bash problem. I will report to bashbug. Thanks, B. Luevelsmeyer
I mailed to 'bug-bash@gnu.org' on 26 Jun 2000 but didn't get an answer. As far as I'm concerned, please close the PR. I consider this to be a bash problem.
State Changed From-To: open->closed Submitter says this is a bash problem.
Steve Kettle mailed me to ask about the state about this old (and closed) problem, and much to my surprise I found it's gone now. I don't know when it vanished. I can't reproduce it anywhere. The oldest system I've got access to is a 4.2-Stable from Jan 4 2001 and has a bash "GNU bash, version 2.04.0(1)-release (i386--freebsd4.1.1)", and there it's gone too. Greetings, B. Luevelsmeyer