Skip to content

Fix for incorrect LC_CTYPE sent from OS X via SSH #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
vasilykolosov wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Fix for incorrect LC_CTYPE sent from OS X via SSH #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6d5eeed
Added .gitignore
Feb 28, 2013
c41cf7b
Added a fix for crash when incorrect LC_CTYPE is sent via ssh from Ma…
Feb 28, 2013
07e243c
Handle deriving locale from OS X SSH remote client in a safer way.
Feb 28, 2013
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
*pyc
fabfile.py
*swp
12 changes: 11 additions & 1 deletion command-not-found
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ try:
import gettext
import locale
import sys
import os
from optparse import OptionParser

from CommandNotFound.util import crash_guard
Expand All @@ -26,7 +27,16 @@ def enable_i18n():
if sys.version < '3':
kwargs["unicode"] = True
cnf.install(**kwargs)
locale.setlocale(locale.LC_ALL, '')

try:
locale.setlocale(locale.LC_ALL, '')
except locale.Error as exc:
# Fixing the case when remote system sends incorrect LC_CTYPE via SSH
if os.environ['LC_CTYPE'] == 'UTF-8': # Mac OS X
# Set the locale based on LANG environmental variable
locale.setlocale(locale.LC_ALL, os.environ.get('LANG', 'C'))
Copy link
Author

@vasilykolosov vasilykolosov Feb 28, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

@zyga zyga Feb 28, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner

@zyga zyga Feb 28, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

else:
raise exc


def fix_sys_argv(encoding=None):
Expand Down