#! / bin / sh vs #! / bin / bash для максимальної портативності

Зазвичай я працюю з серверами Ubuntu LTS , який від того, що я розумію симлінк /bin/shдо /bin/dash. Дуже багато інших дистрибутивів, хоча і посилаються /bin/shна /bin/bash.

З цього я розумію, що якщо сценарій використовується #!/bin/shзверху, він може працювати не однаково на всіх серверах?

Чи пропонується практика, яку оболонку використовувати для скриптів, коли хочеться максимальної переносимості цих сценаріїв між серверами?

Існує приблизно чотири рівні переносимості для скриптів оболонки (що стосується рядка shebang):

1. Найбільш портативний: використовуйте #!/bin/shшебанг і використовуйте лише базовий синтаксис оболонки, визначений у стандарті POSIX . Це має працювати майже на будь-якій системі POSIX / unix / linux. (Ну, за винятком Solaris 10 і новіших версій, які мали справжню спадщину оболонки Борна, передбачаючи POSIX таким невідповідним, як /bin/sh.)

2. Другий за величиною портативний: використовуйте #!/bin/bash(або #!/usr/bin/env bash) лінію shebang та дотримуйтесь функцій bash v3. Це буде працювати в будь-якій системі, яка має bash (у очікуваному місці).

3. Третя найбільш портативна: використовуйте #!/bin/bash(або #!/usr/bin/env bash) лінію shebang та використовуйте функції bash v4. Це не вдасться в будь-якій системі, яка має bash v3 (наприклад, macOS, який повинен використовувати її з ліцензійних причин).

4. Найменше портативний: використовуйте #!/bin/shшебанг і використовуйте розширення bash для синтаксису оболонки POSIX. Це не вдасться в будь-якій системі, яка має щось інше, ніж bash for / bin / sh (наприклад, останні версії Ubuntu). Ніколи цього не робіть; це не просто питання сумісності, це просто невірно. На жаль, це багато помилок.

Моя рекомендація: використовуйте найконсервативніший з перших трьох, який забезпечує всі функції оболонки, необхідні для сценарію. Для максимальної портативності використовуйте варіант №1, але, на мій досвід, деякі функції bash (наприклад, масиви) є досить корисними, що я перейду з №2.

Найгірше, що ви можете зробити, це №4, використовуючи неправильний шебанг. Якщо ви не впевнені, які функції є базовими POSIX, а які - розширення bash, або дотримуйтесь bash shebang (тобто варіант №2), або ретельно протестуйте сценарій із дуже базовою оболонкою (наприклад, тире на ваших серверах Ubuntu LTS). У вікі Ubuntu є хороший список башизмів, на які слід стежити .

У питаннях Unix та Linux "Що означає бути сумісним?" Є кілька дуже хороших відомостей про історію та відмінності між оболонками. і питання Stackoverflow "Різниця між sh і bash" .

Також пам’ятайте, що оболонка - не єдине, що відрізняється між різними системами; якщо ви звикли до Linux, ви звикли до команд GNU, у яких багато нестандартних розширень, яких ви не можете знайти в інших системах unix (наприклад, bsd, macOS). На жаль, тут немає простого правила, ви просто повинні знати діапазон варіацій для команд, які ви використовуєте.

Один з найбільш гидких команд з точки зору переносимості є одним із самих основних: echo. Кожного разу, коли ви використовуєте його з будь-якими параметрами (наприклад, echo -nабо echo -e), або з будь-якими втечами (зворотними косою рисою) у рядку для друку, різні версії будуть робити різні речі. Кожен раз, коли ви хочете надрукувати рядок без передачі рядка після неї, або зі скачками в рядку, використовуйте printfнатомість (і дізнайтеся, як це працює - це складніше, ніж echoє). psКоманда також безлад .

Ще одна загальна річ, яку слід спостерігати, - це нещодавні розширення GNUish до синтаксису командного параметра: старий (стандартний) формат команди полягає в тому, що команді слідують параметри (з одним тире, і кожна опція - одна літера), а потім аргументи команд. Останні (а часто і не портативні) варіанти включають довгі параметри (зазвичай вводяться разом --), що дозволяють опціям приймати після аргументів і використовувати --для відокремлення параметрів від аргументів.

У ./configureсценарії, який готує мову TXR до побудови, я написав наступний пролог для кращої портативності. Сценарій завантажиться сам, навіть якщо #!/bin/shце стара, яка не відповідає стандарту POSIX. (Я будую кожен реліз на Solaris 10 VM).

#!/bin/sh

# use your own variable name instead of txr_shell;
# adjust to taste: search for your favorite shells

if test x$txr_shell = x ; then
  for shell in /bin/bash /usr/bin/bash /usr/xpg4/bin/sh ; do
    if test -x $shell ; then
       txr_shell=$shell
       break
    fi
  done
  if test x$txr_shell = x ; then
    echo "No known POSIX shell found: falling back on /bin/sh, which may not work"
    txr_shell=/bin/sh
  fi
  export txr_shell
  exec $txr_shell $0 ${@+"$@"}
fi

# rest of the script here, executing in upgraded shell

Ідея тут полягає в тому, що ми знаходимо кращу оболонку, ніж та, під якою ми працюємо, і повторно виконуємо скрипт за допомогою цієї оболонки. txr_shellМінлива оточення встановлена, так що повторно виконується скрипт знає , що це рекурсивний екземпляр повторно виконується.

(У моєму сценарії txr_shellзмінна також згодом використовується, точно для двох цілей: по-перше, вона друкується як частина інформаційного повідомлення у висновку сценарію. По-друге, вона встановлюється як SHELLзмінна в Makefile, так що вона makeбуде використовувати це оболонки для виконання рецептів.)

У системі, де /bin/shзнаходиться тире, ви можете бачити, що вищевказана логіка знайде /bin/bashта повторно виконає сценарій із цим.

У вікні Solaris 10 запускається, /usr/xpg4/bin/shякщо Баш не знайдеться.

Пролог написаний на консервативному діалекті оболонки, використовуючи testдля тестів існування файлів, і ${@+"$@"}хитрість для розширення аргументів, що стосуються деяких зламаних старих оболонок (що було б просто, "$@"якби ми опинилися в оболонці, що відповідає POSIX).

Усі варіанти мови оболонки Борна об'єктивно жахливі порівняно з сучасними мовами сценаріїв, такими як Perl, Python, Ruby, node.js і навіть (можливо) Tcl. Якщо вам доведеться зробити що-небудь навіть трохи складне, ви з часом будете щасливішими, якщо замість сценарію оболонки ви будете використовувати одне з перерахованих вище.

Єдиною перевагою мови оболонки, яка все ще є над новими мовами, є те, що щось, що викликає себе /bin/sh, гарантовано існує в усьому, що вважається Unix. Однак це може бути навіть не сумісним з POSIX; багато зі спадщини патентованого Unixes заморозив мову , реалізований /bin/shі утиліт в PATH за замовчуванням перед змінами диктується Unix95 (так, Unix95, двадцять років тому і підрахунок голосів). Може бути набір Unix95 або навіть POSIX.1-2001, якщо вам пощастить, інструменти в каталозі, які не мають стандартних PATH (наприклад /usr/xpg4/bin), але вони не гарантовано існують.

Однак основи Perl є більш імовірними для довільно вибраної установки Unix, ніж Bash. (Під "основами Perl" я маю на увазі, що /usr/bin/perlіснує і є деяка , можливо, досить стара версія Perl 5, і якщо вам пощастить, набір модулів, що постачаються з цією версією інтерпретатора, також доступний.)

Тому:

Якщо ви пишете щось, що повинно працювати скрізь, що вважається Unix (наприклад, сценарій "configure"), вам потрібно користуватися #! /bin/sh, і вам не потрібно використовувати жодних розширень. Сьогодні я б написав сумісну для POSIX.1-2001 оболонку за цієї обставини, але я був би готовий виправити POSIXism, якщо хтось попросить підтримку іржавого заліза.

Але якщо ви не пишете те, що має працювати всюди, тоді, коли ви спокуситесь використовувати будь-який башизм, вам слід зупинитись і переписати всю справу на кращій мові сценаріїв. Ваше майбутнє «я вам вдячне».

(Тому , коли НЕ асигнувати використовувати розширення Bash Для першого порядку: ніколи Для другого порядку: тільки для розширення інтерактивного середовища Bash - наприклад , для забезпечення смарта табуляції завершення і орнаментальні підказок ?.) .