Open ancwrd1 opened 3 years ago
thanks for the issue report, I'll look into it soon
@ancwrd1 Sounds like it could be an issue with our upstream dependency https://github.com/rust-locale/locale_config/ I don't have a Mac to test this properly, would you be happy to try that library with your environment variable and see if it is broken there too?
Considering that dependency looks close to abandoned I'd consider forking it or bringing it into this project, or finding some alternative.
would you be happy to try that library with your environment variable and see if it is broken there too?
Tried the example from locale_config with the same issue.
Generally it depends on the setting of the terminal application, Set locale environment on startup
.
By default this option is turned on.
When it is turned on the LC_CTYPE
env variable is set to UTF-8
and obtaining a locale fails.
When it is turned off there is no LC_CTYPE variable set and locale_config
detects the locale as en-NL
(language set to English, region set to Netherlands).
So to my understanding the fix would be to ignore the LC_CTYPE method if it doesn't contain a proper language-region prefix. Or perhaps don't use it at all on macOS.
@ancwrd1 Would it be possible for you to show the output of your LC_CTYPE
variable?
Yes, here it is:
I tried it on recent macOS versions 10.15 and 11.0.
Depends on this option in the terminal application settings. It is turned on by default.
If this option is turned off the LC_CTYPE
is not set. I think local_config
uses macOS API to get the locale in this case.
@ancwrd1 Thanks! Iteresting ohhh it's literally UTF-8
:laughing: for some reason I assumed that it was some UTF-8 string that wasn't able to be parsed by the locale_config
library. Makes sense though I guess, the variable represents the encoding type?
Makes sense though I guess, the variable represents the encoding type?
Most likely, yes. So shouldn't be used on mac I guess.
locale_config
appears to be fairly abandoned, if someone knows of a good alternative I'm definitely open to replacing it
could we have a tempfix for this, basically having the crate overwrite the env var (in the context of the command only ofc, we wouldnt wanna mess with user settings)?
Looks like we could perhaps integrate https://crates.io/crates/sys-locale which seems better maintained?
Observed on macOS Catalina and Big Sur, when the
LC_CTYPE
envrionment variable is set toUTF-8
(seems like a default for macOS, at least in the terminal application). The DesktopRequester fails with InvalidLanguage error.