Чому #! / Usr / bin / env bash перевершує #! / Bin / bash?

Я бачив в ряді місць, в тому числі рекомендації на цьому сайті ( Що переважне Bash притон? ), Щоб використовувати #!/usr/bin/env bashв перевазі #!/bin/bash. Я навіть бачив, як один заповзятливий чоловік припускає, що використання #!/bin/bashбуло неправильним, і функція bash була б втрачена тим самим.

Все, що сказано, я використовую bash у жорстко контрольованому тестовому середовищі, де кожен привід в обігу по суті є клоном одного головного приводу. Я розумію аргумент переносимості, хоча це не обов'язково застосовується в моєму випадку. Чи є якась інша причина віддавати перевагу #!/usr/bin/env bashальтернативам, і, якщо припустити, що портативність викликає занепокоєння, чи є якась причина, коли її використання може порушити функціональність?

#!/usr/bin/envпошук PATHпо bash, і bashне завжди /bin, особливо в системах , відмінних від Linux. Наприклад, у моїй системі OpenBSD він є /usr/local/bin, оскільки він був встановлений як необов'язковий пакет.

Якщо ви абсолютно впевнені bash, що /binбудете і завжди будете, немає шкоди, якщо ввести це безпосередньо у свій шебанг - але я б рекомендував проти цього, оскільки всі сценарії та програми живуть поза тим, що ми спочатку вважаємо, що вони матимуть.

Стандартне розташування bash є /bin, і я підозрюю, що це справедливо для всіх систем. Однак, що робити, якщо вам не подобається ця версія bash? Наприклад, я хочу використовувати bash 4.2, але bash на моєму Mac є в 3.2.5.

Я можу спробувати перевстановити bash, /binале це може бути поганою ідеєю. Якщо я оновлю ОС, вона буде перезаписана.

Однак я міг би встановити bash in /usr/local/bin/bashі встановити PATH для:

PATH="/usr/local/bin:/bin:/usr/bin:$HOME/bin"

Тепер, якщо я вказую bash, я отримую не старий сирий /bin/bash, а новий, блискучий /usr/local/bin. Приємно!

За винятком моїх скриптів оболонок, які мають цей !# /bin/bashшебанг. Таким чином, коли я запускаю сценарії оболонки, я отримую таку стару і паршиву версію bash, яка навіть не має асоціативних масивів.

Використання /usr/bin/env bashвикористовуватиме версію bash, знайдену в моєму PATH. Якщо я встановив свій PATH, щоб він /usr/local/bin/bashбув виконаний, це баш, який будуть використовувати мої сценарії.

Це рідко можна побачити з bash, але це набагато частіше з Perl та Python:

• Деякі версії Unix / Linux, орієнтовані на стабільність , іноді відстають від випуску цих двох мов сценарію. Не так давно Perl RHEL був у 5,8,8 - восьмирічній версії Perl! Якщо хтось хотів використовувати більш сучасні функції, вам довелося встановити власну версію.
• Такі програми, як Perlbrew та Pythonbrew, дозволяють встановлювати кілька версій цих мов. Вони залежать від сценаріїв, які маніпулюють вашим PATH, щоб отримати бажану версію. Жорсткий кодування шляху означає , що я не можу запустити мій сценарій під варіння .
• Не так давно (гаразд, це було давно), що Perl і Python не були стандартними пакетами, що входять до більшості систем Unix. Це означало, що ви не знаєте, де встановлені ці дві програми. Це було під /bin? /usr/bin? /opt/bin? Хто знає? Використання #! /usr/bin/env perlозначало, що я не повинен був знати.

І тепер, чому ви не повинні використовувати #! /usr/bin/env bash

Коли шлях у шебангу твердо кодований, я повинен бігти з цим перекладачем. Таким чином, #! /bin/bashзмушує мене використовувати встановлену за замовчуванням версію bash. Оскільки функції bash дуже стабільні (спробуйте запустити 2.x версію сценарію Python під Python 3.x), дуже малоймовірно, що мій конкретний сценарій BASH не працюватиме, і оскільки мій bash скрипт, ймовірно, використовується цією системою та іншими системами , використання нестандартної версії bash може мати небажані наслідки. З великою ймовірністю я хочу переконатися, що стабільна стандартна версія bash використовується з моїм сценарієм оболонки. Таким чином, я, мабуть, хочу чітко кодувати шлях у моєму шебангу.

Для виклику bashце небагато зайвих наборів. Якщо у вас є кілька bashбінарних файлів, як ваш власний в ~ / bin, але це також означає, що ваш код залежить від $ PATH, що має в ньому правильні речі.

Це зручно для таких речей, як pythonхоча. Існують сценарії обгортки та середовища, які призводять до використання альтернативних pythonбінарних файлів.

Але нічого не втрачається, використовуючи точний шлях до бінарного, якщо ви впевнені, що це бінарне, якого ви дійсно хочете.

Існує багато систем, у яких немає Bash /bin, FreeBSD та OpenBSD, щоб назвати лише декілька. Якщо ваш сценарій призначений для перенесення для багатьох Unices, ви можете використовувати його #!/usr/bin/env bashзамість #!/bin/bash.

Зауважте, що це не відповідає дійсності sh; для Bourne-сумісних скриптів я використовувати виключно #!/bin/sh, так як я думаю , що майже кожен Unix існує має shв /bin.

Я вважаю за краще обгортати основну програму в сценарій, як показано нижче, щоб перевірити всі bashнаявні в системі. Краще мати більше контролю над версією, яку вона використовує.

#! /usr/bin/env bash

# This script just chooses the appropriate bash
# installed in system and executes testcode.main

readonly DESIRED_VERSION="5"

declare all_bash_installed_on_this_system
declare bash

if [ "${BASH_VERSINFO}" -ne "${DESIRED_VERSION}" ]
then
    found=0

    all_bash_installed_on_this_system="$(\
        awk -F'/' '$NF == "bash"{print}' "/etc/shells"\
        )"

    for bash in $all_bash_installed_on_this_system
    do
        versinfo="$( $bash -c 'echo ${BASH_VERSINFO}' )"
        [ "${versinfo}" -eq "${DESIRED_VERSION}" ] && { found=1 ; break;}
    done
    if [ "${found}" -ne 1 ]
    then
        echo "${DESIRED_VERSION} not available"
        exit 1
    fi
fi

$bash main_program "$@"

 #!/usr/bin/env bash

це, безумовно, краще, тому що він знаходить виконавчий шлях bash від змінної вашого системного середовища.

Перейдіть до своєї оболонки та введіть Linux

env

Він надрукує всі ваші змінні середовища.

Перейдіть до сценарію оболонки та введіть

echo $BASH

Він надрукує ваш шлях bash (відповідно до списку змінних оточуючих середовищ), який ви повинні використовувати для створення правильного шляху shebang у вашому сценарії.