I have a problem with a slightly customised Debian image that I'm trying to do some headless work on. The problem is that the installed locales list has been reduced to this:
C
en_GB
en_GB.iso88591
en_GB.iso885915
en_GB.utf8
POSIX
However, when I log in as root (with an otherwise as-vanilla profile), I find this:
~# set | grep LC_
LC_CTYPE=en_US.UTF-8
That's the only LC_ environment variable set, and presumably that means that it's being explicitly set somewhere (and given that /etc/default/locale only contains LANG=en_GB, I can't see any other alternative). However, I can't see where it is being set, and the fact that it's wrong is preventing, for example, postgresql-8.4 from installing. I know I can do an
LC_CTYPE=en_GB apt-get install postgresql-8.4
to work around this, but I'd really like to understand where this setting comes from, and I really dislike the idea of installing an otherwise-unnecessary locale to make this go away. So: where does this LC_CTYPE setting come from, and how do I make it go away?
Best Answer
For future reference, I have found the problem, and it's nothing to do with Bash.
The problem is that sshd_config has the following entry:
This allows my local environment variables named LC_whatever (including LC_CTYPE, the problematic one) to override remote settings so, when I connected, the ssh process set its environment variables accordingly, and the bash process dutifully inherited them. Nowhere in this process is there a check that the LC_CTYPE setting is valid on the far side of the SSH connection.
My temporary fix is to specify a known good LC_CTYPE in the specific command I run on the far side. I don't know what the "correct" solution to this is.