Cel #! / Usr / bin / python3

Zauważyłem to w kilku językach skryptowych, ale w tym przykładzie używam Pythona. W wielu samouczkach zaczynali się #!/usr/bin/python3od pierwszego wiersza. Nie rozumiem, dlaczego to mamy.

• Czy system operacyjny nie powinien wiedzieć, że to skrypt w Pythonie (oczywiście jest zainstalowany, ponieważ robisz do niego odniesienie)
• Co jeśli użytkownik używa systemu operacyjnego, który nie jest oparty na Uniksie
• Język jest instalowany w innym folderze z dowolnego powodu
• Użytkownik ma inną wersję. Zwłaszcza, gdy nie jest to pełny numer wersji (jak Python3 vs Python32)

Jeśli już, widziałem, jak to psuje skrypt Pythona z powodów wymienionych powyżej.

#!/usr/bin/python3to linia shebang .

Linia z hukiem określa, gdzie znajduje się tłumacz. W tym przypadku python3tłumacz znajduje się w /usr/bin/python3. Linia A shebang może być również bash, ruby, perltłumacza lub w jakimkolwiek innym języku skryptowym, na przykład: #!/bin/bash.

Bez linii shebang system operacyjny nie wie, że jest to skrypt w języku Python, nawet jeśli ustawisz flagę wykonywania skryptu i uruchomisz go w ten sposób ./script.py. Aby skrypt działał domyślnie w python3, wywołaj go jako python3 script.pylub ustaw linię shebang.

Możesz użyć #!/usr/bin/env python3do przenoszenia w różnych systemach, jeśli mają one interpreter języka zainstalowany w różnych lokalizacjach.

To się nazywa hasz. Jeśli uruchomisz skrypt z powłoki, sprawdzi on pierwszą linię, aby dowiedzieć się, jaki program powinien zostać uruchomiony, aby zinterpretować skrypt.

System operacyjny inny niż Unix będzie używał własnych reguł, aby dowiedzieć się, jak uruchomić skrypt. Na przykład Windows użyje rozszerzenia nazwy pliku, a #pierwsza linia zostanie potraktowana jako komentarz.

Jeśli ścieżka do pliku wykonywalnego Pythona jest nieprawidłowa, skrypt nie powiedzie się. Łatwo jest tworzyć łącza do rzeczywistego pliku wykonywalnego z dowolnej lokalizacji określonej w standardowej konwencji.

Ta linia pomaga znaleźć plik wykonywalny programu, który będzie uruchamiał skrypt. Ten zapis shebang jest dość standardowy w większości języków skryptowych (przynajmniej taki, jaki jest używany w systemach operacyjnych dla dorosłych).

Ważnym aspektem tej linii jest określenie, który interpreter będzie używany. Na przykład w wielu dystrybucjach Linuksa zorientowanych na programowanie normalne jest jednoczesne zainstalowanie kilku wersji języka Python.

Python 2.x i Python 3 nie są w 100% kompatybilne, więc ta różnica może być bardzo ważna. Zatem #! /usr/bin/pythoni #! /usr/bin/python3nie są takie same (i nie są takie same, #! /usr/bin/env python3jak zaznaczono w innym miejscu na tej stronie.

1. A oto jak .

2. To jest ignorowane.

3. Nie będzie działać i należy go zmienić, aby wskazywał właściwą lokalizację. Lub envpowinien być używany.

4. Nie będzie działać i prawdopodobnie nie będzie działać w innej wersji niezależnie od tego.

Aby wyjaśnić, jak działa linia shebang w systemie Windows, z dokumentu 3.7 Python :

• Jeśli pierwsza linia pliku skryptu zaczyna się od #!, Jest nazywana linią „shebang”. Linux i inne systemy operacyjne podobne do Uniksa mają natywną obsługę takich linii i są one powszechnie używane w takich systemach do wskazywania sposobu wykonywania skryptu.
• Python Launcher dla Windows umożliwia używanie tych samych funkcji ze skryptami Pythona w systemie Windows
• Aby umożliwić przenoszenie linii shebang w skryptach Pythona między systemami Unix i Windows, program uruchamiający obsługuje szereg poleceń „wirtualnych”, które określają, którego interpretera należy użyć. Obsługiwane polecenia wirtualne to:
  • / usr / bin / env python
    • Forma / usr / bin / env linii shebang ma jeszcze jedną specjalną właściwość. Przed wyszukaniem zainstalowanych interpreterów Pythona, ten formularz przeszuka wykonywalną ścieżkę PATH w poszukiwaniu pliku wykonywalnego Pythona. Odpowiada to zachowaniu programu Unix env, który przeprowadza wyszukiwanie PATH.
  • / usr / bin / python
  • / usr / local / bin / python
  • pyton

Właściwie określenie typu pliku jest bardzo skomplikowane, więc teraz system operacyjny nie może po prostu wiedzieć. Może dokonać wielu przypuszczeń na podstawie -

• rozbudowa
• UTI
• MIM

Ale wiersz poleceń nie przejmuje się tym wszystkim, ponieważ działa na ograniczonej warstwie kompatybilnej wstecz, od kiedy ten wymyślny nonsens nic nie znaczył. Jeśli klikniesz dwukrotnie to na pewno, nowoczesny system operacyjny może to zrozumieć - ale jeśli uruchomisz go z terminala, to nie, ponieważ terminal nie dba o twoje fantazyjne interfejsy API do wpisywania plików dla konkretnego systemu operacyjnego.

Odnośnie innych punktów. To wygoda, podobnie można biegać

python3 path/to/your/script

Jeśli twojego Pythona nie ma w określonej ścieżce, to nie zadziała, ale zwykle instalujemy takie rzeczy, aby takie rzeczy działały, a nie na odwrót. Właściwie nie ma znaczenia, czy jesteś pod * nix, to twoja powłoka decyduje, czy rozważy tę linię, ponieważ jest to shellcode. Na przykład możesz uruchomić bashpod Windows.

W rzeczywistości możesz całkowicie pominąć tę linię, oznacza to po prostu, że dzwoniący będzie musiał określić interpretera. Nie umieszczaj także swoich tłumaczy w niestandardowych lokalizacjach, a następnie próbuj wywoływać skrypty bez zapewnienia tłumacza.