bash prompt misbehaving - correction.
Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. The main difference between debian etch and debian lenny in this respect appears to be that the default locale is now unicode (en_US.UTF-8). I remember seeing other posts relative to this type of problem, possibly on this list, but searching online, I could not find anything that explained what is happening or provided a workaround/resolution. Debian lenny has the following installed: $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. My guess is that the non-printable characters in my bash prompt that switch colors interfere with bash's notion of the prompt's length? root's bash prompt is defined like so: PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] I removed the color escape sequences from my user's bash prompt via a: $ PS1=[\$(date +%T)]...@\h:\w]\\$ .. and now everything is back to normal. Seems to confirm my above speculations. In any case it's just a minor annoyance that I can live with for now, but all the same, I would be grateful if anyone could provide some useful pointers to documentation or bug reports that would help understand what is happening, and possibly a workaround. If this is really a bug in the version of bash that I am running, I will eventually upgrade to a version of bash where the issue is fixed, so please let me know if this an option. Thanks, CJ
Re: bash prompt misbehaving - correction.
Chris Jones schrieb: ... After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. ... PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] This works correctly with bash 4.0.24. Regards, Bernd -- Bernd Eggink http://sudrala.de
Re: bash prompt misbehaving - correction.
On Tue, Jun 30, 2009 at 05:23:27AM EDT, Bernd Eggink wrote: Chris Jones schrieb: ... After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. ... PS1=\[\033[0;41m\][\$(date +%T)]...@\h:\w]\\$\[\033[0m\] This works correctly with bash 4.0.24. I guess I need to check the NEWS file of this version to see if there are any fixes that might have addressed this issue since 3.2.29. CJ
Re: bash prompt misbehaving - correction.
Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. The main difference between debian etch and debian lenny in this respect appears to be that the default locale is now unicode (en_US.UTF-8). I remember seeing other posts relative to this type of problem, possibly on this list, but searching online, I could not find anything that explained what is happening or provided a workaround/resolution. Debian lenny has the following installed: $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash prompt misbehaving - correction.
On Tue, Jun 30, 2009 at 08:30:35AM EDT, Chet Ramey wrote: Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. [..] $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. Is there anything that happened between 3.2.39 3.2.49 that might account for this, or would you suspect a problem with my setup? I just ran the same test again on a plain xterm with TERM=xterm and no additional layers such as gnu/screen and I'm still getting the same result. If this is of interest, what kind of information about my context should I provide. Or should I run a test with a more current version of bash and if I can't recreate, forget about it? Thanks, CJ
Re: bash prompt misbehaving - correction.
Chris Jones wrote: On Tue, Jun 30, 2009 at 08:30:35AM EDT, Chet Ramey wrote: Chris Jones wrote: Not sure whether this is a bug in my version of bash, but I copied over my colored PS1 prompts from debian etch - regular user root - and some convenient keyboard actions are misbehaving. After retrieving a command from the history via a CTRL-R, an ensuing CTRL-A moves the cursor to somewhere in the middle of the prompt and CTRL-E is short of the retrieved command's end by some ten characters. [..] $ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. I can't reproduce this behavior with bash-3.2.49. Is there anything that happened between 3.2.39 3.2.49 that might account for this, or would you suspect a problem with my setup? I would assume that one of the patches addresses this problem. Or should I run a test with a more current version of bash and if I can't recreate, forget about it? You should always test against the most current version. In your case, you can test against more recent versions of bash-3.2 or bash-4.0. If the work to fix the problem has already been done and released, why not take advantage of it? Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
