В чем разница между #! / Usr / bin / env bash и #! / Usr / bin / bash?

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

Таким образом, вам не нужно искать его в определенном месте в системе, поскольку эти пути могут находиться в разных местах в разных системах. Пока он на вашем пути, он его найдет.

Одним из недостатков является то, что вы не сможете передать более одного аргумента (например, вы не сможете написать /usr/bin/env awk -f), если хотите поддерживать Linux, как POSIX расплывчато о том, как интерпретировать строку, а Linux интерпретирует все, что находится после первого пробела, для обозначения единственного аргумента. Вы можете использовать /usr/bin/env -S в некоторых версиях env, чтобы обойти это, но тогда скрипт станет еще менее переносимым и сломается на довольно новых системах (например, даже в Ubuntu 16.04, если не позже).

Другой недостаток заключается в том, что, поскольку вы не вызываете явный исполняемый файл, у него есть вероятность ошибок и проблем с безопасностью многопользовательских систем (например, если кому-то удалось получить свой исполняемый файл с именем bash на вашем пути).

#!/usr/bin/env bash #lends you some flexibility on different systems
#!/usr/bin/bash     #gives you explicit control on a given system of what executable is called

В некоторых ситуациях первый может быть предпочтительным (например, запуск скриптов python с несколькими версиями python без необходимости переделывать исполняемую строку). Но в ситуациях, когда в центре внимания безопасность, предпочтительнее второе, поскольку оно ограничивает возможности внедрения кода.

Использование #!/usr/bin/env NAME заставляет оболочку искать первое совпадение NAME в переменной окружения $ PATH. Это может быть полезно, если вы не знаете абсолютный путь или не хотите его искать.

Если сценарии оболочки начинаются с #!/bin/bash, они всегда будут запускаться с bash из /bin. Однако если они начнут с #!/usr/bin/env bash, они будут искать bash в $PATH, а затем начнут с первого, которое смогут найти.

Почему это может быть полезно? Предположим, вы хотите запускать bash сценарии, для которых требуется bash 4.x или новее, но в вашей системе установлено только bash 3.x, и в настоящее время ваш дистрибутив не предлагает более новую версию, или вы не являетесь администратором и не можете изменить то, что установлено на эта система.

Конечно, вы можете загрузить исходный код bash и создать свой собственный bash с нуля, например, поместив его в ~/bin. И вы также можете изменить свою $PATH переменную в вашем .bash_profile файле, чтобы включить ~/bin в качестве первой записи (PATH=$HOME/bin:$PATH, поскольку ~ не будет расширяться в $PATH). Если вы сейчас вызовете bash, оболочка сначала будет искать его в $PATH по порядку, поэтому она начинается с ~/bin, где и найдет ваш bash. То же самое происходит, если сценарии ищут bash с помощью #!/usr/bin/env bash, поэтому теперь эти сценарии будут работать в вашей системе с использованием вашей пользовательской сборки bash.

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

Самым большим недостатком env является то, что некоторые системы допускают только один аргумент, поэтому вы не можете этого сделать #!/usr/bin/env <interpreter> <arg>, поскольку системы будут рассматривать <interpreter> <arg> как один аргумент (они будут рассматривать его, как если бы выражение было заключено в кавычки), и поэтому env будет искать интерпретатор по имени <interpreter> <arg>. Обратите внимание, что это проблема не самой команды env, которая всегда позволяла передавать несколько параметров, а парсера shebang системы, который анализирует эту строку даже перед вызовом env. Между тем, это было исправлено в большинстве систем, но если ваш сценарий хочет быть сверхпортативным, вы не можете полагаться, что это было исправлено в системе, которую вы будете запускать.

Это может даже иметь последствия для безопасности, например если sudo не был настроен для очистки среды или $PATH был исключен из очистки. Позвольте мне продемонстрировать это:

Обычно /bin - это хорошо защищенное место, только root может там что-либо изменить. Ваш домашний каталог не является, однако, любая программа, которую вы запускаете, может вносить в него изменения. Это означает, что вредоносный код может поместить поддельный bash в какой-то скрытый каталог, изменить ваш .bash_profile, чтобы включить этот каталог в ваш $PATH, так что все сценарии, использующие #!/usr/bin/env bash, в конечном итоге будут работать с этим поддельным bash. Если sudo сохраняет $PATH, у вас большие проблемы.

Например. Считайте, что инструмент создает файл ~/.evil/bash со следующим содержанием:

#!/bin/bash

if [ $EUID -eq 0 ]; then
  echo "All your base are belong to us..."
  # We are root - do whatever you want to do
fi

/bin/bash "$@"

Сделаем простой скрипт sample.sh:

#!/usr/bin/env bash

echo "Hello World"

Подтверждение концепции (в системе, где sudo сохраняет $PATH):

$ ./sample.sh
Hello World

$ sudo ./sample.sh
Hello World

$ export PATH="$HOME/.evil:$PATH"

$ ./sample.sh
Hello World

$ sudo ./sample.sh
All your base are belong to us...
Hello World

Обычно все классические оболочки должны быть расположены в /bin, и если вы не хотите размещать их там по какой-либо причине, на самом деле не проблема разместить символическую ссылку в /bin, указывающую на их реальное местоположение (или, возможно, /bin сам является символической ссылкой ), поэтому я всегда буду использовать #!/bin/sh и #!/bin/bash. Слишком много всего могло бы сломаться, если бы они больше не работали. Это не значит, что POSIX потребует эту позицию (POSIX не стандартизирует имена путей и, следовательно, вообще не стандартизирует функцию shebang), но они настолько распространены, что даже если система не предложит /bin/sh, она, вероятно, все равно понимать #!/bin/sh и знать, что с этим делать, возможно, это только для совместимости с существующим кодом.

Но для более современных, нестандартных, необязательных интерпретаторов, таких как Perl, PHP, Python или Ruby, на самом деле нигде не указано, где они должны быть расположены. Они могут быть в /usr/bin, но они также могут быть в /usr/local/bin или в совершенно другой ветви иерархии (/opt/..., /Applications/... и т. Д.). Вот почему они часто используют синтаксис #!/usr/bin/env xxx shebang.

Вместо явного определения пути к интерпретатору, как в /usr/bin/bash/, с помощью команды env, интерпретатор ищется и запускается оттуда, где он был впервые найден. У этого есть плюсы и минусы

Я считаю это полезным, потому что, когда я не знал о env, до того, как я начал писать скрипт, я делал это:

type nodejs > scriptname.js #or any other environment

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