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 terminal.app 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 terminal.app.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (16 by maintainers)
yup, #1087 looks like it works for me
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_CTYPEsimply 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}.UTF8and use it for bothLC_CTYPEandLANG.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
localeIdentifierto get the locale. Perhaps we should specifically requestcountryCodeandlanguageCode, join them, and use that to avoid getting the additional locale data.