Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 220621 - "LC_ALL=something" in ~/.bashrc affects bash (breaks command line editing) but is not shown by locale command
Summary: "LC_ALL=something" in ~/.bashrc affects bash (breaks command line editing) bu...
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-06 17:14 UTC by Erik
Modified: 2011-02-13 19:09 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.info,4.13 KB, text/plain)
2008-05-06 19:19 UTC, Erik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik 2008-05-06 17:14:01 UTC
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".
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2008-05-06 18:20:03 UTC
Is this in a terminal window under X or on a tty? It's certainly not a problem particular to bash.
Comment 2 Erik 2008-05-06 18:43:01 UTC
(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).
Comment 3 Jeroen Roovers (RETIRED) gentoo-dev 2008-05-06 19:14:11 UTC
emerge --info, please.
Comment 4 Erik 2008-05-06 19:19:33 UTC
Created attachment 152149 [details]
emerge --info
Comment 5 Jeroen Roovers (RETIRED) gentoo-dev 2008-05-06 19:51:46 UTC
What bash prompt do you use, btw?
Comment 6 Erik 2008-05-06 20:01:42 UTC
(In reply to comment #5)
> What bash prompt do you use, btw?

I tried various, for example:
PS1="0123456789 >"

Comment 7 Erik 2008-05-07 07:10:24 UTC
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.
Comment 8 Jan Kundrát (RETIRED) gentoo-dev 2008-05-07 09:49:54 UTC
(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.

Comment 9 Erik 2008-05-07 09:54:58 UTC
(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.
Comment 10 Jeroen Roovers (RETIRED) gentoo-dev 2008-05-07 16:21:32 UTC
(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.
Comment 11 Erik 2008-05-07 17:38:49 UTC
(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.
Comment 12 Erik 2008-05-07 19:41:21 UTC
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.
Comment 13 Erik 2008-05-08 20:54:31 UTC
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.
Comment 14 Evert 2011-02-13 11:16:12 UTC
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.