Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?

share|improve this question
    
check /etc/environment; it's where it used to be set. other options are /etc/bash.bashrc and /etc/profile.d/something.sh, but nothing should have automatically installed the variable in those files. –  Michael Lowman Jul 21 '11 at 14:48
    
and you did run locale-gen, right? –  Michael Lowman Jul 21 '11 at 14:49
    
locale-gen has been run, there's nothing in /etc/environment (empty file). I can't see anything relevant in /etc/bash.bashrc, and the only thing in /etc/profile.d is bash_completion.sh which, from an eyeball scan and a grep LC_, looks irrelevant. –  regularfry Jul 21 '11 at 15:07
    
try running bash --noprofile --norc. if this doesn't pick up the LC_CTYPE, your issue must be in one of those startup files –  Michael Lowman Jul 21 '11 at 16:17
    
It's not being set when I run bash --login or bash --noprofile --norc. I can run LC_CTYPE=FOO bash <whatever> and LC_CTYPE is set to FOO inside the new shell in both cases. –  regularfry Jul 21 '11 at 16:47
show 2 more comments

2 Answers

up vote 1 down vote accepted

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:

AcceptEnv LANG LC_*

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.

share|improve this answer
add comment

You can install the missing locales:

apt-get install debconf
dpkg-reconfigure locales

Choose the locales you would like to install.

share|improve this answer
    
That's not an ideal solution: the image I was working on is a cut-down image for VM deployment. The reason locales were cut out was for space reasons, and even if I wanted to install locales I'd have to do it for every single VM I connected to. –  regularfry Jul 16 '12 at 11:37
    
You wanted the "correct" solution... –  Michael Hampton Jul 16 '12 at 14:15
    
Adding more packages to a misconfigured system is rarely "correct", in any sense. –  regularfry Jul 16 '12 at 16:20
    
If you don't want locales, then get rid of all of them and just use the C locale. Then you can forget about the whole thing. :) –  Michael Hampton Jul 16 '12 at 16:22
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.