Fix for incorrect LC_CTYPE sent from OS X via SSH #1
Conversation
command-not-found
Outdated
There was a problem hiding this comment.
I would do os.environ.get("LANG", "some default") to be extra paranoid.
Why do you split() it on the '.' character? That will return an array, did you want to get the first component of that?
There was a problem hiding this comment.
I would do os.environ.get("LANG", "some default") to be extra paranoid.
Makes sense
Why do you split() it on the '.' character? That will return an array, did you want to get the first component of that?
No, but you're right — there's no need to do a split. I was a bit confused by example in documentation, where setlocale is called with a tuple ("en_us", "UTF-8") as a second argument, but a string is okay too.
Fixing that in next commit.
There was a problem hiding this comment.
Note that the spec says you can put some kind of expressions there, like en_US.UTF-8;fr_FR.UTF-8 for example, I think it's best to minimize our need to parse that
There was a problem hiding this comment.
Removed unnecessary split() (You were absolutely right about that!)
Do you think falling back to 'C' is a good idea? I tested that just now, and cnf seems to behave correctly with LC_CTYPE set to 'C'. Besides, it's pretty universal.
There was a problem hiding this comment.
Using C can be tricky. At least when you start with LANG=C, python behaves like it's the 1980 again and sys.stdout.encoding is ASCII. That break everything, including us trying to print the input line (say I mistype ł a non-ASCII) character. For all intents and purposes I would not do that.
I think it's worth separating translation support, which depends on lots of stuff working right from just not crashing on weird settings and random garbage as input. We should strive not to crash above all. Getting translation support should be a cherry on top that we do when everything else is working.
There was a problem hiding this comment.
For a quick test, use a non-en locale, try installing something that you can still operate without understanding and has translations enabled. That will trigger all kinds of issues. I recommend a far-east language (but I don't know what has translations ATM) or something as simple as German, which should have translations and enough non-ASCII characters to cause trouble.
If that works for you (using LANG=C fallback) then say so, I assume it breaks so far
2 participants
This fix is maybe somewhat too specific, since it first checks if LC_CTYPE is set to "UTF-8".
I tested this on several systems, and it does solve (kind of) the problem. Basically, if
locale.setlocale(locale.LC_ALL, '')fails, it calls the following instead:'en_us' and 'UTF-8' are derived from LANG environmental variable, which is specific to remote Ubuntu system.