alacritty: LC_CTYPE set to some strange (invalid?) value in alacritty

(macOS, current master branch)

My .bashrc sets LANG=en_GB.UTF-8 and LC_COLLATE=C; in I get:


In alacritty LC_CTYPE is set to en_GB@currency=EUR.UTF-8:


I guess the value of LC_CTYPE somehow comes from my macOS setting (where I have overridden £ with €), but it doesn’t seem valid (at least, it causes nano to not correctly display unicode files) and I do not expect my locale settings to be impacted by launching a terminal.

Also, in alacritty I get a __CF_USER_TEXT_ENCODING=0x1F5:0:0, which is absent in

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 22 (16 by maintainers)

Most upvoted comments

yup, #1087 looks like it works for me

do you remember why that is needed in macOS?

Without setting them, macOS doesn’t seem to source the bash_profile or per user shell configuration. The terminal would start at the root directory / and generally feel really broken. On Linux, these environment variables are already present from the parent process.

Nice research on this! I think I would lean towards continuing to set LC_CTYPE simply because iTerm does so by default. It can always be overridden from a .bashrc or something.

I think the fix here is to generate "{languageCode}_{countryCode}.UTF8 and use it for both LC_CTYPE and LANG.

Nevermind, I did not had LANG set in my zshrc, works now

But then it should be fine once that’s merged. 😃

We’re using localeIdentifier to get the locale. Perhaps we should specifically request countryCode and languageCode, join them, and use that to avoid getting the additional locale data.