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. Jul 21, 2011 at 14:48
  • and you did run locale-gen, right? Jul 21, 2011 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, 2011 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 Jul 21, 2011 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, 2011 at 16:47

2 Answers 2


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.


You can install the missing locales:

apt-get install debconf
dpkg-reconfigure locales

Choose the locales you would like to install.

  • 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, 2012 at 11:37
  • You wanted the "correct" solution... Jul 16, 2012 at 14:15
  • Adding more packages to a misconfigured system is rarely "correct", in any sense.
    – regularfry
    Jul 16, 2012 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. :) Jul 16, 2012 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.