[Pkg-zsh-devel] Bug#654225: zsh: Multibyte fails when $LANG.utf variable is not set

Frank Terbeck ft at bewatermyfriend.org
Mon Jan 2 14:30:32 UTC 2012


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





More information about the Pkg-zsh-devel mailing list