Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I thought I'd switch to zsh, so I did just that with chsh -s /usr/bin/zsh user, unfortunately, it broke my compose key (unresponsive both in the console and in an X terminal); also, when I read email in emacs rmail, Swedish characters are not displayed correctly (diamonds in the console, question marks in an X terminal) - but it is possible to display them, for example if I cat the mail files instead.

To possibly reinitialize the compose key, I run setupcon again as superuser but it didn't help. In /etc/default/keyboard, this line is present XKBOPTIONS="compose:lwin,terminate:ctrl_alt_bksp".

As for the compose key in X, and the character set in both the console and an X terminal, I'm clueless because I can't remember anytime "setting up" those things, they just worked.

To double check, I switched back to bash with chsh -s /bin/bash user, and everything worked as before. I examined .profile and .bashrc to see if I possibly had done some keyboard/charmap initialization there, but I couldn't find anything to that extent.

zsh --version
zsh 4.3.17 (i686-pc-linux-gnu)
share|improve this question
Look at .bash_profile vs zprofile and equivalent in /etc, especially about locals (LC_* or LANG variables) – Stéphane Chazelas Oct 27 '12 at 20:58
@StephaneChazelas: 100% correct, I put LANG="en_US.UTF-8" in /etc/default/locale and that solved both problems. If you post your comment as an answer, I'll accept it. – Emanuel Berg Oct 27 '12 at 23:49
Forgot to say, that didn't quite do it in X, had to put export LANG="en_US.UTF-8" in .xsessionrc. – Emanuel Berg Oct 28 '12 at 0:47
up vote 1 down vote accepted

Since bash or zsh is in no way responsible for handling the Compose key, what must have broken is your session startup files. Check your ~/.profile or ~/.bash_profile, or /etc/profile, for commands that might have a bearing on the locale setting, such as values for the LANG or LC_CTYPE environment variables. It's likely that your keyboard configuration no longer matches your application's idea of the system character set.

You can make zsh read your .profile by putting the following command in your ~/.zprofile:

emulate -R sh -c '. ~/.profile'

If that doesn't suffice (especially under X), tell us what distribution (e.g. Ubuntu, Fedora, …), what desktop environment (or window manager, e.g. KDE4, Gnome2, XFCE4, …) and what display manager (the GUI program where you enter your user name and password, e.g. GDM, KDM, Lightdm, …) you use.

share|improve this answer
I managed to solve this by setting LANG at two different places, one for the console, and one for X: see my comments above for exactly what I did (but it was Mr. Chazelas who got my on the right LANG track). This solved both problems, including the compose key, but I won't pretend this is anything I understand. Maybe, without the specified encoding, the computer didn't even notice that the compose key was pressed? – Emanuel Berg Oct 28 '12 at 19:01
@EmanuelBerg It probably did, but then transmitted the wrong character from the application. I admit I don't recognize the failure mode from your description. You're apparently using a UTF-8 locale; it would help to know how your machine is set up — distribution, desktop environment, display manager. – Gilles Oct 28 '12 at 19:04
Oh, you still want it. Sure: Debian (sid), with GNOME remnants (e.g., Metacity), but I disabled gdm3 and instead autologin to the ttys and then onwards to X with xinit (so I run urxvt and Metacity in .xinitrc). – Emanuel Berg Oct 28 '12 at 19:12
@EmanuelBerg Weird, export LC_CTYPE=en_US.UTF-8 in .profile should suffice then (it's what I do, except that I don't use Metacity). – Gilles Oct 28 '12 at 19:58
Yes, export LC_CTYPE=en_US.UTF-8 in .zprofile works. It is better than the above solution as it is one fix (not two), and only in the user's directory (perhaps LC_CTYPE is less heavy-handed than LANG as well). As for the weirdness about it, I think bash loads some file, either by default or setup by me (i.e., run from some other file), either way, in that file, the locale is set. When I switched to zsh, this file was suddenly not run. – Emanuel Berg Oct 28 '12 at 21:57

Your Answer


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.