Problem occurs with bash-3.2_p17-r1, bash-3.2_p33 and bash-3.2_p39. [ebuild R ] app-shells/bash-3.2_p39 USE="nls -afs -bashlogger -plugins -vanilla" locale is sv_SE.UTF-8 Reproducible: Always Steps to Reproduce: 1. Type aaåbb. 2. Move the cursor to the beginning (left arrow). 3. Move the cursor to the end (right arrow). When the arrow passes the letter 'å', the whole commad is moved one position to the left, overwriting the last character of the prompt (' ') and leaving a garbage character ('b') at the end. Moving up/down in the command history also causes the problem. This moving back and forth can be repeaded until the whole prompt has been eaten and there is a long trail of 'b's at the end. As a work-around I emerged app-shells/tcsh, changed all /bin/bash to /bin/sh in /etc/passwd and did "cd /bin&&rm sh&&ln -s tcsh sh".
Is this in a terminal window under X or on a tty? It's certainly not a problem particular to bash.
(In reply to comment #1) > Is this in a terminal window under X or on a tty? It's certainly not a problem particular to bash. It happens in both Konsole and tty (any place where an interactive bash is running).
emerge --info, please.
Created attachment 152149 [details] emerge --info
What bash prompt do you use, btw?
(In reply to comment #5) > What bash prompt do you use, btw? I tried various, for example: PS1="0123456789 >"
I tried to see whether it is caused by readline. I tried other software that uses it and shows a prompt, but they all work (php -a, python, civserver, gnuplot, gdb). Only bash fails.
(In reply to comment #0) > "cd /bin&&rm sh&&ln -s tcsh sh" That was a really bad thing to do. Please don't file any bugs before you fix this. The C shell isn't compatible with bourne shell so things *will* break.
(In reply to comment #8) > (In reply to comment #0) > > "cd /bin&&rm sh&&ln -s tcsh sh" > > That was a really bad thing to do. Please don't file any bugs before you fix > this. The C shell isn't compatible with bourne shell so things *will* break. Now I have /bin/sh pointing to bash and users having /bin/zsh as their shell (uninstalled tcsh). zsh fells strange but at least it works.
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #0) > > > "cd /bin&&rm sh&&ln -s tcsh sh" > > > > That was a really bad thing to do. Please don't file any bugs before you fix > > this. The C shell isn't compatible with bourne shell so things *will* break. > > Now I have /bin/sh pointing to bash and users having /bin/zsh as their shell > (uninstalled tcsh). zsh fells strange but at least it works. Bash works fine for most of us... I have tried to reproduce the behaviour exactly as you described and couldn't. jeroen@elmer ~ $ locale LANG= LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL=sv_SE.UTF-8 Please post the output of the locale command.
(In reply to comment #10) > Bash works fine for most of us... I have tried to reproduce the behaviour > exactly as you described and couldn't. > > jeroen@elmer ~ $ locale > LANG= > LC_CTYPE="sv_SE.UTF-8" > LC_NUMERIC="sv_SE.UTF-8" > LC_TIME="sv_SE.UTF-8" > LC_COLLATE="sv_SE.UTF-8" > LC_MONETARY="sv_SE.UTF-8" > LC_MESSAGES="sv_SE.UTF-8" > LC_PAPER="sv_SE.UTF-8" > LC_NAME="sv_SE.UTF-8" > LC_ADDRESS="sv_SE.UTF-8" > LC_TELEPHONE="sv_SE.UTF-8" > LC_MEASUREMENT="sv_SE.UTF-8" > LC_IDENTIFICATION="sv_SE.UTF-8" > LC_ALL=sv_SE.UTF-8 Please execute "unset LC_ALL;bash" and then try to reproduce the problem in that shell.
My locale: LANG=sv_SE.UTF-8 LC_CTYPE="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_PAPER="sv_SE.UTF-8" LC_NAME="sv_SE.UTF-8" LC_ADDRESS="sv_SE.UTF-8" LC_TELEPHONE="sv_SE.UTF-8" LC_MEASUREMENT="sv_SE.UTF-8" LC_IDENTIFICATION="sv_SE.UTF-8" LC_ALL= So the difference is that I have LANG set and you have not and you override everything with LC_ALL while I do not.
I just discovered that I had LC_ALL=sv_SE in ~/.bashrc. This was overriding the other settings and caused the problem in bash. The reason that I did not discover it immediately is that locale reported "LC_ALL=" (empty)! However if i export LC_ALL=something in an interactive bash and then execute locale, it shows something. (If I change the line in ~/.bashrc to "export LC_ALL=something", locale will also get it.) I assume that this is a bug (maybe in bash or locale). So I had this in /etc/env.d/02locale: LANG=sv_SE.UTF-8 This set all regular internationalization variables. ~/.bashrc had this: . /etc/profile LC_ALL=sv_SE So the "LC_ALL=sv_SE in ~/.bashrc affected bash (broke it) but did not show up with the locale command! Can anyone reproduce that? That behaviour is insidious.
Nice discussion we last had. Why do people and/or scripts use: export PATH="$PATH:/some/other/dir/bin" export is not needed because PATH is already exported in /etc/profile. export means: MARK the variable for inheritance by child processes (and childs of childs etc). changing a variable does not affect the export flag. Now, you did not export LC_ALL, so it is not inherited by child processes, so only seen by bash. The command "locale" is a child process, so it didn't see LC_ALL. This is absolutely normal behaviour. Furthermore, you set LC_ALL=sv_SE and forgot .UTF-8 so that's probably the cause of the behaviour you described. So, if you set a LC_* or LANG variable, you should make sure it is exported (/etc/env.d/* or /etc/profile.d/*.sh or ~/.bash_profile Variables *only* meant for bash itself (like PS1, aliases and functions) should go in ~/.bashrc. Furthermore, it may be useful to have ". /etc/profile" in ~/.bashrc in a time when you regularly change /etc/env.d/* or /etc/profile.d/*.sh, but normally it's wrong to have ". /etc/profile" in .bashrc. So, I think this bug should be resolved as invalid.