Czy istnieje przenośny sposób uruchamiania skryptu Pythona z powłoki bez zapisywania pełnej ścieżki?

Na przykład w Linuksie chciałbym mieć go w swoim katalogu domowym

<code>cd ~
</code>

aby móc uruchomić skrypt Pythona o nazwie run.py, który ma powiedzmy ~ / long / path / to / run.py, ale chcę go uruchomić po prostu wpisując

<code>python run.py
</code>

zamiast

<code>python ~/long/path/to/run.py
</code>

Mam nadzieję na jakąś listę ścieżek wyszukiwania, która zawiera kilka katalogów, tak jak zmienna PATH, więc python run.py uruchamia pierwszy run.py, który napotyka w jednym z katalogów.

Zastanawiałem się, jak zamienić run.py w plik wykonywalny i dodać jego katalog do zmiennej systemowej PATH, ale nie mogłem znaleźć przenośnego sposobu na wykonanie skryptu Pythona.

EDYTOWAĆ

Rok później, po zapytaniu, jestem trochę mniej noobem i widzę, że moje pytanie nie było zbyt jasne i nie miało większego sensu, więc po pytaniu na głos wyjaśnię kilka rzeczy.

1) Przenośny.

Kiedy o to zapytałem, powiedziałem przenośny. Jednakże, jakie przenośne środki nie są w tym przypadku jasne, a ja nie przywiązywałem do tego większego nacisku.

platformy: powinny działać na POSIX (Linux, MacOS itp.) i Windows

to wciąż nie ma większego sensu, ponieważ Windows używacmd.exei używa POSIXsh, więc każdy może uruchamiać polecenia z inną składnią. Powiedzmy, że najbardziej przenośną rzeczą możliwą byłoby podanie tego samego wejścia do obush icmd.exe, uruchamiając skrypt Pythona w obu przypadkach. W takim przypadku można uruchomić to samo polecenie z ANSI Csystem funkcja, która używash na POSIX icmd w systemie Windows. ANSI C jest jedną z niewielu rzeczy, które są wspólne dla Windows i POSIX, w tym przypadku pytanie ma sens.

2) Plik wykonywalny

Dalej zdanieturning run.py into an executable, nie jest bardzo jasne. Mówiłem o strategii Linuksachmod +x run.py, dodaj shebang#!/usr/bin/env pythoni dodając swój katalog system dodaje ~ / long / path / to / zmienna środowiskowa PATH. Ale to nie zadziała w przypadku Windows, ponieważ Windows nie obsługuje właściwości metadanych pliku wykonywalnego, takich jak Linux i ponieważ / usr / bin / env nie musi istnieć w systemie Windows.

3) Rozszerzenie

Wreszcie w mojej głowie liczyłem na rozwiązanie, które nie określi, jaki jest rodzaj uruchamiania pliku, więc jeśli pewnego dnia zdecydujemy się go utworzyć, powiedzmy, plik perla, żaden interfejs się nie zmieni.

Dlatego piszęrun.py byłoby źle, ponieważ określałoby typ pliku; lepiej byłoby móc pisać tylkorun