Хижина всегда является тем же как каталогом установки интерпретатора?

Как другие отметили, строка хижины должна относиться к фактическому файлу, который существует.

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

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

Иначе должен отредактировать сценарий для обращения к правильному пути в системе.

Еще один способ обойти это состоит в том, чтобы использовать /usr/bin/env, который найдет исполняемый файл в Вашем ПУТИ.

Таким образом вместо:

#!/usr/bin/python

Запись:

#!/usr/bin/env python

Таким образом, люди просто имеют к символьной ссылке /usr/bin/env в случае необходимости, а не каждый отдельный исполняемый файл.

Конечно, исполняемый файл все еще должен быть в Вашем ПУТИ для этого для работы...

Как Вы видите, существует номер 100%-е чистое решение.Помните: "Хуже Лучше" (:

#! строка (хижины) должна указать исполняемый файл, который на самом деле существует. Если обе работы над Вашей системой, это означает, что Вам установили Python в обоих местах. Или, возможно, символьная ссылка.

Обычно, Вы делали бы попытку ошибки для использования интерпретатора, который не существует:

anthony@Zia:~$ /tmp/test 
bash: /tmp/test: /usr/local/bin/python: bad interpreter: No such file or directory

Если Вы вместо этого запускаете скрипт как это, то путь, вероятно, не имеет значения:

anthony@Zia:~$ python /tmp/test
anthony@Zia:~$ 

Поэтому Вы запускаете Python непосредственно и передаете его аргумент. Python затем решает открыть тот файл и рассматривать его как сценарий. В первом случае ядро пытается запустить скрипт как исполняемый файл. Это проверяет его, замечает строку хижины и пытается преобразовать его во вторую форму, таким образом, это может на самом деле выполнить его. Это перестало работать если путь, данный после #! на самом деле не существует.

Хижина является комбинацией следующих символов: #! когда это появляется в первой строке сценария. Следующая строка всегда является путем к интерпретатору. Я проверил бы что точно /usr/bin/python и /usr/local/bin/python . Возможно, что один из них является символьной ссылкой в другой. Могли Вы, обеспечить вывод следующих команд:

• ls -l /usr/bin/python
• ls -l /usr/local/bin/python