Как запустить скрипт Python переносимо без указания его полного пути

есть ли портативный способ запуска скрипта python из оболочки без написания полного пути?

например, в Linux, я хотел бы в то время как в моем домашнем каталоге

cd ~

чтобы иметь возможность запускать скрипт python под названием run.py то есть, скажем, ~/long/path/to/run.py, но я хочу запустить его, просто набрав

python run.py

вместо

python ~/long/path/to/run.py

я бы надеялся на какой-то список путей поиска, который содержит несколько каталогов, таких как переменная PATH, так что python run.py запускает первый run.py он встречается в одном из каталогов.

я рассмотрел возможность поворота run.py в исполняемый файл и добавление в его каталог переменной system PATH, но не удалось найти портативный способ сделать исполняемый файл скрипта python.

редактировать

через год после того, как я задал его, я немного меньше нуб, и я вижу, что мой вопрос был не очень ясным и не имел большого смысла, поэтому после вопрос upvote я проясню некоторые вещи.

1) портативный.

когда я спросил об этом, я сказал портативный. Однако, что означает portable, в этом случае неясно, и я не придал этому большого значения.

• платформы: должны работать на POSIX (Linux, MacOS и т. д.) и Windows

• это все еще не имеет большого смысла, так как windows использует cmd.exe, а POSIX использует sh, чтобы каждый мог запускать команды с помощью другой синтаксис. Итак, предположим, что наиболее портативной вещью было бы подавать один и тот же вход в оба sh и cmd.exe запуск скрипта Python в обоих случаях. В этом случае вы можете запустить ту же команду из ANSI C system функция, которая использует sh на POSIX и cmd на Windows. ANSI C - одна из немногих вещей, общих для Windows и POSIX, в этом случае вопрос имеет смысл.

2) исполняемый

далее, фраза turning run.py into an executable, не очень ясно. Тем самым я говорил о стратегии Linux chmod +x run.py, добавить shebang #!/usr/bin/env python и добавление его каталога система добавляет ~/long / path / to / переменную среды PATH. Но тогда это не будет работать для windows, потому что windows не поддерживает свойство метаданных исполняемого файла, такое как Linux, и потому что /usr/bin/env не обязательно существует в Windows.

3) расширение

наконец, в моей голове я надеялся на решение, которое не указывает, что это за файл, так что если когда-нибудь мы решим сделать его, скажем, файлом perl, никакие интерфейсы не изменятся.

поэтому пишу run.py было бы плохо, потому что он указывал бы тип файла; было бы лучше иметь возможность писать просто run