Если сценарии оболочки начинаются с #!/bin/bash, они всегда будут работать с bashс /bin. Если они однако начать с #!/usr/bin/env bash, они будут искать bashв $PATHи затем начать с первыми они могут найти.
Почему это было бы полезно? Предположим, вы хотите запустить bashсценарии, для которых требуется bash 4.x или новее, но в вашей системе установлена только bash3.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синтаксис Шебанга.