Dlaczego ten komunikat o błędzie python jest generowany za każdym razem, gdy wpisuję nonsensowne polecenie?

Ilekroć wpisuję dowolne polecenie „nonsens”, generowany jest ten komunikat o błędzie python. Normalne polecenia działają dobrze. Masz pomysł, jak to debugować?

$ somenonexistingcommand
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site.py", line 553, in <module>
    main()
  File "/usr/local/lib/python2.7/site.py", line 535, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/local/lib/python2.7/site.py", line 268, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/local/lib/python2.7/site.py", line 243, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/local/lib/python2.7/site.py", line 233, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/local/lib/python2.7/sysconfig.py", line 535, in get_config_var
    return get_config_vars().get(name)
  File "/usr/local/lib/python2.7/sysconfig.py", line 434, in get_config_vars
    _init_posix(_CONFIG_VARS)
  File "/usr/local/lib/python2.7/sysconfig.py", line 298, in _init_posix
    raise IOError(msg)
IOError: invalid Python installation: unable to open /usr/include/python2.7/pyconfig.h (No such file or directory)
$ echo this works fine, however
this works fine, however
$

EDYCJA - po naprawieniu mojego / usr / bin / python, otrzymuję teraz inny komunikat o błędzie python:

$ yetanothernonexistingcommand
Traceback (most recent call last):
  File "/usr/lib/command-not-found", line 10, in <module>
    import CommandNotFound
ImportError: No module named CommandNotFound

Jakoś python jest uruchamiany za każdym razem, gdy błędnie wpisuję polecenie.

Ok, to sprawia, że ​​wszystko jest trochę jaśniejsze. command-not-foundto program w języku Python, który działa, gdy twoje polecenie nie znajduje się w systemie. (Jego funkcją jest sugerowanie alternatyw i poprawek w przypadku pomyłki itp.) Patrz /usr/bin/command-not-found. Próbuje zaimportować CommandNotFoundmoduł, ale nie jest w stanie tego zrobić, wyraźnie wskazując na zepsutą instalację Pythona. Nie znam się tak dobrze command-not-found, ale myślę, że naprawienie instalacji Pythona rozwiąże problem.

Aby to nieco rozwinąć, prawdopodobnie dzieje się tak, że command-not-foundmoduł znajduje się w miejscu, gdzie domyślny python go nie szuka. Zasadniczo problem ze ścieżką.

Sugestie debugowania:

1) Na początek, z czego pochodzi wyjście

$ which python

i do jakiego pakietu / instalacji należy ten plik?

2) Jakie dane wyjściowe dla Twojej instalacji odpowiadają poniższemu kodowi? Ścieżka tutaj jest ścieżką importu tego pytona.

$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/local/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/usr/lib/pymodules/python2.6', '/usr/lib/pymodules/python2.6/gtk-2.0', '/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode']

Natknąłem się na to, kiedy zaktualizowałem z wersji 2.6 dostarczonej wraz z moją instalacją ubuntu do Pythona 3.2, ustawiając domyślną alternatywę na 3.2 zamiast 2.6.

Jeśli spojrzysz na swój /etc/bash.bashrcplik, jest wiersz, który mówi mu, aby uruchomił ten skrypt Pythona, aby szukać alternatyw w repozytoriach. Jest do tego pakiet, jednak nie można go usunąć po aktualizacji. Ja po prostu przeniósł /usr/share/command-not-founda /usr/lib/command_not_found_handleri ponownie mój termin i działa jak dobry ol”bash: command not found.

Miałem ten sam błąd po zainstalowaniu Python 3.5.0 na moim Ubuntu 14.04 LTS (który ma systemowy python w wersji 3.4.0).

Po otwarciu /usr/lib/command-not-foundzdałem sobie sprawę, że ten błąd jest spowodowany przez system wykonujący ten skrypt za pomocą nowo zainstalowanego Python3.5.0, ponieważ instalacja Python3.5.0 powoduje, że system używa go podczas wpisywania python3.

Ten błąd można łatwo naprawić, zmieniając pierwszy wiersz z

#!/usr/bin/python3

do

#!/usr/bin/python3.4  

Problem dotyczy $PATHzmiennej środowiskowej. Najprawdopodobniej to popsułeś. Powinien być podobny do tego:

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Zobacz ten wątek Linux Mint: http://forums.linuxmint.com/viewtopic.php?f=18&t=119561 .

Możesz naprawić swój $PATHw powłoce za pomocą tego polecenia:

$ export PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

To jest tymczasowe! Jeśli problem będzie się powtarzał przy ponownym uruchomieniu, najprawdopodobniej ukryłeś $PATHw jednym z plików instalacyjnych swojego środowiska pod /etc.

Pakiet „Command-not-found” jest narzędziem linux; odpowiada na nieznane polecenia w wierszu poleceń, nie tylko w sesjach Pythona. (Widzę, że istnieje również pakiet python o tej nazwie).

Ma między sobą Pythona, tzn. Używa Pythona po uruchomieniu; więc wyjaśnia, dlaczego python jest wywoływany za każdym razem, gdy wpiszesz polecenie, którego powłoka nie może znaleźć na twojej ŚCIEŻCE.

Widzę, że istnieje pakiet „apt” do zainstalowania polecenia nieznalezionego w Linuksie; dla systemu Linux Debian jest to skatalogowane pod adresem:

https://packages.debian.org/sid/admin/command-not-found

Komentując wszystkie linie odpowiedzialne za command-not-foundw /etc/bash.bashrcrozwiązał problem, który został stworzony przez przełączanie wersji Pythona.