Morten Bo Johansen wrote: > I could not get multibyte support to work in zsh, even if I had a, what > seemed to me, perfectly working utf-8 environment. I then checked the > output from the "locale" command and noticed that all my LC_.* variables > were set to "da_DK.utf8" whereas the $LANG variable missed the "utf8" > extension. As soon as I changed it to include this extension, then > multibyte support worked. As noted, the lack of this setting has not > affected me at all except in zsh (multibyte support worked fine in bash > for instance). I believe that zsh should check both the values of the > LC_CTYPE variable and the LANG variable.
Locale settings work like this: LC_* variables control the different pieces of the puzzle, when one of those is not set `LANG' is used as a fallback. `LC_ALL' is special, because it overrides all other LC_* variables and `LANG' becomes meaningless. [...] > Locale: LANGÚ_DK.utf8, LC_CTYPEÚ_DK.utf8 (charmap=UTF-8) (ignored: LC_ALL set > to da_DK.utf8) You're setting `LC_ALL'. So the setting of `LANG' shouldn't matter at all. I've got one system that only sets "LC_CTYPE=en_US.UTF8" to something UTF-8-ish and that works for me (LC_* set to `POSIX' - LANG and LC_ALL both unset). I did take a quick look at the involved code and I didn't see anything obviously wrong with it. `LANG' should *not* matter with `LC_ALL' set. If it does, that's a bug. Can you give a minimal zsh setup and a simple way to trigger the problem you're seeing for further inspection? Regards, Frank -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
