Почему лучше использовать “#!/usr/bin/env ИМЯ” вместо “#!/path/to/NAME” как моя хижина?

Поскольку/usr/bin/env может интерпретировать Ваш $PATH, который делает сценарии более портативными.

#!/usr/local/bin/python

Только запустит Ваш скрипт, если Python будет установлен в/usr/local/bin.

#!/usr/bin/env python

Интерпретирует Ваш $PATH, и найдите Python в любом каталоге в Вашем $PATH.

Таким образом, Ваш сценарий является более портативным, и будет работать без модификации над системами, где Python установлен как /usr/bin/python, или /usr/local/bin/python, или даже пользовательские каталоги (которые были добавлены к $PATH), как /opt/local/bin/python.

Мобильность является единственной причиной, использующей env предпочтен твердым кодированным путям.

Добавление другого примера здесь:

Используя env также полезно, когда Вы хотите совместно использовать сценарии между несколькими rvm среды, например.

Выполнение этого на cmd строке, шоу, какая рубиновая версия будет использоваться когда #!/usr/bin/env ruby используется в сценарии:

env ruby --version

Поэтому, когда Вы используете env, можно использовать различные рубиновые версии через rvm, не изменяя сценарии.

Определение полного пути более точно в данной системе. Оборотная сторона - то, что это слишком точно. Предположим, что Вы понимаете, что установка системы Perl слишком стара для Ваших сценариев, и Вы хотите использовать свое собственное вместо этого: затем необходимо отредактировать сценарии и изменение #!/usr/bin/perl кому: #!/home/myname/bin/perl. Хуже, если у Вас есть Perl в /usr/bin на некоторых машинах, /usr/local/bin на других, и /home/myname/bin/perl на все же других машинах затем необходимо было бы поддержать три отдельных копии сценариев и выполнить соответствующий на каждой машине.

#!/usr/bin/env повреждения, если PATH плохо, но почти что-либо - также. Попытка работать с плохим PATH очень редко полезно, и указывает, что Вы знаете очень мало о системе, на которой работает сценарий, таким образом, Вы не можете полагаться ни на какой полный путь так или иначе.

Существует две программы, на местоположение которых можно полагаться почти на каждом варианте Unix: /bin/sh и /usr/bin/env. Некоторые неясные и главным образом варианты Unix на пенсии имели /bin/env без наличия /usr/bin/env, но Вы вряд ли встретитесь с ними. Современные системы имеют /usr/bin/env точно из-за его широкого использования в хижинах. /usr/bin/env что-то, на что можно рассчитывать.

Кроме /bin/sh, единственное время необходимо использовать полный путь в хижине, - когда сценарий не предназначен, чтобы быть портативным, таким образом, можно рассчитывать на известное местоположение для интерпретатора. Например, сценарий удара, который только работает над Linux, может безопасно использовать #!/bin/bash. Сценарий, который только предназначен, чтобы использоваться внутренний, может полагаться на конвенции местоположения интерпретатора дома.

#!/usr/bin/env действительно имеет оборотные стороны. Это более гибко, чем определение полного пути, но все еще требует знания названия интерпретатора. Иногда Вы могли бы хотеть выполнить интерпретатор, который не находится в $PATH, например, в месте относительно сценария. В таких случаях можно часто делать многоязычный сценарий, который может быть интерпретирован и стандартной оболочкой и желаемым интерпретатором. Например, для создания сценария Python 2 портативным оба к системам, где python Python 3 и python2 Python 2, и к системам где python Python 2 и python2 не существует:

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
else
  exec python "$0" "$@"
fi
'''
# real Python script starts here
def …

Специально для жемчуга, с помощью #!/usr/bin/env плохая идея по двум причинам.

Во-первых, это не портативно. На некоторых неясных платформах ENV не находится в/usr/bin. Во-вторых, как Keith Thompson отметил, это может доставить неприятности с передающими аргументами на строке хижины. Максимально портативное решение - это:

#!/bin/sh
exec perl -x "$0" "$@"
#!perl

Для получения дополнительной информации о том, как это работает, см. 'perldoc perlrun' и что это говорит о-x аргументе.

Причина различия между ними заключается в том, как выполняются сценарии.

Использование /usr/bin/env (который, как упоминалось в других ответах, не находится в /usr/bin на некоторых операционных системах) необходимо, потому что вы не можете просто поставить имя исполняемого файла после #! - это должен быть абсолютный путь. Это потому, что #! работает на более низком уровне, чем оболочка. Он является частью двоичного загрузчика ядра. Это можно проверить. Поместите это в файл и пометьте его как исполняемый:

#!bash

echo 'foo'

Вы увидите, что он печатает подобную ошибку при попытке запуска:

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

Если файл помечен как исполняемый и начинается с #! , ядро (которое не знает ни о $PATH, ни о текущем каталоге: это пользовательские концепции) будет искать файл, используя абсолютный путь. Поскольку использование абсолютного пути проблематично (как упоминалось в других ответах), кто-то придумал трюк: Вы можете запустить /usr/bin/env (который почти всегда находится в этом месте), чтобы запустить что-нибудь, используя $PATH.

Если вы пишете чисто для себя или для своей работы, и местоположение переводчика, которое вы звоните, всегда в том же месте, все средства используют прямой путь. Во всех других случаях используйте #! / USR / BIN / ENV .

Вот почему: в вашей ситуации Python Python интерпретатор был таким же место, независимо от того, какой синтаксис вы использовали, но для многих людей он мог установить в другом месте. Хотя большинство основных переводчиков программирования расположены в / USR / BIN / , много нового программного обеспечения по умолчанию для / usr / local / bin / .

Я бы даже поспорил всегда использовать #! / USR / BIN / ENV , потому что если у вас есть несколько версий одного и того же интерпретатора, и вы не знаете, что ваша оболочка будет по умолчанию, то вы Вероятно, следует это исправить.

Есть еще две проблемы с использованием #!/usr/bin/env

1. Это не решает проблему указания полного пути к интерпретатору, а просто перемещает его в env.

   env не более гарантированно находится в /usr/bin/env, чем bash гарантированно находится в /bin/bash или python в /usr/bin/python.

2. env перезаписывает ARGV[0] именем интерпретатора (например, bash или python).

   Это предотвращает появление имени вашего скрипта в выводе, например, ps (или изменяет, как/где оно появляется) и делает невозможным его поиск, например, ps -C scriptname.sh

[update 2016-06-04]

И третья проблема:

3. Изменение PATH - это больше работы, чем просто редактирование первой строки скрипта, особенно когда сценарий таких правок тривиален. например:

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo. py

   Добавить или предварительно добавить каталог в $PATH довольно просто (хотя вам все равно придется редактировать файл, чтобы сделать его постоянным - ваш ~/.profile или что-то еще - и это далеко не просто для сценария ТАКОГО редактирования, потому что PATH может быть установлен в любом месте сценария, а не в первой строке).

   Изменить порядок каталогов PATH значительно сложнее.... и гораздо сложнее, чем просто отредактировать #! #.

   И у вас остаются все остальные проблемы, которые дает использование #!/usr/bin/env.

   @jlliagre предлагает в комментарии, что #!/usr/bin/env полезно для тестирования вашего скрипта с несколькими версиями интерпретаторов, "только изменяя их порядок PATH / PATH"

   Если вам нужно это сделать, гораздо проще просто иметь несколько #! строк в верхней части вашего скрипта (это просто комментарии везде, кроме самой первой строки) и вырезать/копировать-вставить ту, которую вы хотите использовать сейчас, в первую строку.

   В vi это будет просто: переместите курсор на #! , затем набрать dd1GP или Y1GP. Даже в таком тривиальном редакторе, как nano, использование мыши для копирования и вставки займет секунды.

В целом, преимущества использования #!/usr/bin/env в лучшем случае минимальны, и уж точно даже близко не перевешивают недостатки. Даже преимущество "удобства" в значительной степени иллюзорно.

IMO, это глупая идея, продвигаемая определенным типом программистов, которые считают, что операционные системы - это не то, с чем нужно работать, это проблема, которую нужно обходить (или в лучшем случае игнорировать).

PS: вот простой скрипт для изменения интерпретатора сразу нескольких файлов.

change-shebang.sh:

#!/bin/bash

interpreter="$1"
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

Запустите его, например, как change-shebang.sh python2.7 *.py или change-shebang.sh $HOME/bin/my-experimental-ruby *.rb