1

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?

Improve this question
7
  • 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
    Commented Jul 21, 2011 at 14:48
  • and you did run locale-gen, right?
    – Michael Lowman
    Commented 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
    Commented 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
    – Michael Lowman
    Commented 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
    Commented Jul 21, 2011 at 16:47

2 Answers 2

Reset to default
1

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
0

You can install the missing locales:

apt-get install debconf
dpkg-reconfigure locales

Choose the locales you would like to install.

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .