Błąd krytyczny w języku Python: Py_Initialize: nie można uzyskać kodowania ustawień regionalnych… Błąd składni: niepoprawna składnia Przerwano (zrzut rdzenia)

16

Zainstalowałem anakondę, uruchamiając

bash Anaconda-2.2.0-Linux-x86_64.sh

polecenie w moim systemie Ubuntu 14.04, który został pomyślnie zainstalowany, po czym zostałem poproszony o wyeksportowanie mojej nowej /home/username/anaconda/binzmiennej środowiskowej $ PATH.

Dzięki temu mogłem korzystać ze wszystkich funkcji anakondy, w tym IDE, a także z powodzeniem korzystać ze wszystkich poleceń opartych na Condach.

Następnym razem, gdy uruchamiam system, każde źle wpisane polecenie widziało

Fatal Python error: Py_Initialize: Unable to get the locale encoding
  File "/usr/local/lib/python2.7/encodings/__init__.py", line 123
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax
Aborted (core dumped)

błąd. (Wszystkie polecenia oprócz pythonspecyficznych)

Po śledzeniu kilku postów wymiany stosu i postów askubuntu, a także zauważeniu, że mój $PYTHONPATHzostał ustawiony usr/local/lib/python2.7, próbowałem

export PYTHONPATH=$PYTHONPATH:/home/username/anaconda/lib/python2.7

ale to nie pomogło.

To sprawiło, że przejrzałem całą sagę usuwania pakietów i ponownej instalacji oraz oczywiście wiele aktualizacji i uaktualnień, aby samodzielnie rozwiązać problem.

conda info -a zwroty:

CIO_TEST: <not set>
CONDA_DEFAULT_ENV: <not set>
CONDA_ENVS_PATH: <not set>
LD_LIBRARY_PATH: <not set>
PATH: /home/username/anaconda/bin:/home/username/Scala-sbt/sbt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/username/bin:/usr/local/java/jdk1.8.0_20/bin
PYTHONHOME: <not set>
PYTHONPATH: /usr/local/lib/python2.7:/home/username/anaconda/bin/python

Komenda

which python

zwroty

/home/username/anaconda/bin/python

i

echo "$PATH"

zwroty

/home/username/anaconda/bin:/home/username/Scala-sbt/sbt/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/username/bin:/usr/local/java/jdk1.8.0_20/bin

Wiem, że ma to związek ze sposobem, w jaki ustawiam zmienne ścieżki, szczególnie w tym, ~/.bashrcw którym Anaconda automatycznie dodała folder / home / username / anaconda / bin do $PATHzmiennej (Stało się to podczas drugiej instalacji Anacondy po tym, jak ją najpierw usunąłem ).

Nie zmodyfikowałem żadnej innej zmiennej środowiskowej w żadnym z ~/.profilelub ~/.bashrc.


Dodałem linię eksportu PYTHONPATH do mojej ~/.bashrcprzed ponownym uruchomieniem.

Wszystkie funkcje Anacondy działają teraz, chociaż ten sam Fatal Python error: Py_Initialize: Unable to get the locale encodingbłąd pojawia się zamiast zwykłego nieznanego błędu polecenia, w przypadku większości źle wpisanych poleceń.

Będę się nad tym zastanawiał i zredagował moją odpowiedź (lub odniesie się do istniejących odpowiedzi, jeśli takie istnieją), jak tylko dowiem się, dlaczego tak się dzieje.

samirzach
źródło

Odpowiedzi:

11

Poleciłbym rozbroić PYTHONPATH. Zasadniczo nie jest potrzebne i powoduje, że coś się psuje, powodując, że jeden Python ładuje rzeczy z innego Pythona (w tym przypadku wygląda na to, że system Python 3 próbuje załadować coś, co zostało napisane dla Python 2).

asmeurer
źródło
3
Szczere przeprosiny za spóźnioną odpowiedź, proszę pana. Czy poprzez rozbrajanie PYTHONPATH masz na myśli ręczne konfigurowanie przy każdym uruchomieniu? Anaconda obecnie uruchamia Python 2.7.10 i nie zainstalowałem Python 3, więc dlaczego miałby się pojawiać ten błąd? Powodem, dla którego pytam, jest to, że informacje Condy dla katalogów witryny użytkownika określają zmienną PYTHONPATH jako PYTHONPATH: /home/usrnme/anaconda/lib/python2.7:/usr/local/lib/python2.7. Jeśli mam usunąć wiersz PYTHONPATH: / home / usrnme / anaconda .. z mojego ~ / .bashrc, błąd nadal będzie występował, a także żadna z funkcji Anacondy nie zadziała, dopóki nie ustawię go ponownie.
samirzach
3

W ciągu ostatnich kilku dni miałem podobne problemy, więc prześledziłem to do tego, jak bash obsługuje „nie znaleziono polecenia”. W Ubuntu 14.04 (i Linux Mint 17, w której korzystam ze skryptów 14.04), /etc/bash.bashrc ma następującą funkcję:

if [ -x /usr/lib/command-not-found ]; then
    function command_not_found_handle {
        # check because c-n-f could've been removed in the meantime
        if [ -x /usr/lib/command-not-found ]; then
            /usr/bin/python /usr/lib/command-not-found -- $1
            return $?
        else
           return 127
        fi
    }
fi

Jednak / usr / lib / command-not-found został przepisany dla Pythona 3. Obsługuje on komendę /etc/bash.bashrc z:

if sys.version < '3':                                                       
    # We might end up being executed with Python 2 due to an old            
    # /etc/bash.bashrc.                                                     
    import os                                                               
    if "COMMAND_NOT_FOUND_FORCE_PYTHON2" not in os.environ:                 
        os.execvp("python3", [sys.argv[0]] + sys.argv)

To wywołuje „python3” ze ścieżki, a nie daje bezpośredniej ścieżki. Aby to naprawić, należy zmienić wiersz 22 w / usr / lib / command-not-found

os.execvp("python3", [sys.argv[0]] + sys.argv)

do

os.execv("/usr/bin/python3", [sys.argv[0]] + sys.argv)

To wydaje się być błędem w Ubuntu, a nie w Anaconda. Sprawdzę, czy pojawi się w późniejszych dystrybucjach.

rymac
źródło
1

Po zainstalowaniu python3 w standardowych lokalizacjach i zrozumieniu, że potrzebuję sudo, aby go użyć, zainstalowałem lokalnie, używając tego w moim katalogu domowym:

python3 -m venv env_py3
source env_py3/bin/activate

Ale miał więcej błędów. Po prostu rozbrojenie PYTHONPATH na instancji AWS Amazon Linux działało dla mnie świetnie.

Pasowy
źródło
1

Mój problem był nieco inny: jako jeden użytkownik mogłem uruchomić python, ale jako inny użytkownik nie (mam ten sam błąd co OP). Wreszcie dowiedziałem się, że uprawnienia i własność /usr/lib/python3.5 zostały przykręcone. Powodem tego było to, że rekurencyjnie ustawiałem uprawnienia i własność virtualenv, co skończyło się również modyfikacją celów dowiązań symbolicznych (targetin /usr/lib/python3.5 ).

Wskazówka: Użyj, strace pythonaby dowiedzieć się, co się dzieje podczas uruchamiania Pythona. Kiedy użyłem strace, mogłem wyraźnie zobaczyć PERMISSION_DENIED na /usr/lib/python3.5 .

Juuso Ohtonen
źródło
-3

Miałem podobny problem w systemie Windows - usunąłem zmienną systemową PYTHONHOME. Spróbuję przetłumaczyć rozwiązanie na angielski. Mój komputer> Właściwości> Zaawansowane ustawienia systemu> Zmienne środowiskowe, poszukaj zmiennej PYTHONHOME i usuń ją.

użytkownik790300
źródło