-
-
Notifications
You must be signed in to change notification settings - Fork 402
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make it a bit harder to run into the LC_ALL thing
This behavior is stupid. Respecting LC_ALL, or anything else for that matter, over the encoding fucking noted in the fucking file is a bad decision, and someone should feel bad. I don't know why it makes things break in the specific and bizarre way it does, but it does, and there's no possible good reason for it. Closes #984. Fuck.
- Loading branch information
Showing
2 changed files
with
14 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It might be safer to use locale.getlocale() and then check if the second part of the tuple is UTF-8, since python3 will run into issues when the locale encoding is not UTF8. There are a bunch of non-unicode locales that a Linux system (for example) can use, and you can type
locale -a | grep \. | grep -v utf8
in your console to list all of the ones known to your version of libc.By default, even on a normal environment, LC_ALL is unset, and then the value of LANG is is used. If both LC_ALL and LANG is unset, then the value of one of the other LC_(something) env vars is used (you can see them all by typing
locale
in your console).If all of them are unset (for example if you type
unset LANG
, which resets all the others) the locale will change to "POSIX" (which is, I think, equivalent to "C") and that will cause problems.