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:


However, when I log in as root (with an otherwise as-vanilla profile), I find this:

~# set | grep LC_

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?

  • 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

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.

| improve this answer | |

You can install the missing locales:

apt-get install debconf
dpkg-reconfigure locales

Choose the locales you would like to install.

| 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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