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?

regularfry
  • 215
  • 2
  • 11
  • 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 ` and LC_CTYPE is set to FOO inside the new shell in both cases. – regularfry Jul 21 '11 at 16:47
  • In that case you should check `/etc/profile`, `~/.bash_profile`, `~/.bash_login`, and `~/.profile`. If any of those files that exist source (`. /usr/local/custom.sh` or `source /usr/local/custom.sh`) other files, check them too. Your `LC_CTYPE` is probably being set in one of them. – Michael Lowman Jul 21 '11 at 19:53
  • None of those turned out to be the problem, it was a little more subtle than that. See below for what I found. – regularfry Jul 22 '11 at 10:36

2 Answers2

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.

regularfry
  • 215
  • 2
  • 11
0

You can install the missing locales:

apt-get install debconf
dpkg-reconfigure locales

Choose the locales you would like to install.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 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