Коли я повинен використовувати #! / Bin / bash, а коли #! / Bin / sh?

Коли це #!/bin/bashбільше, ніж #!/bin/shу сценарії оболонки?

Коротко:

• Існує кілька оболонок, які реалізують надмножину специфікації POSIX sh . У різних системах /bin/shможе бути посилання на ash, bash, dash, ksh, zsh, & c. (Хоча це завжди буде сумісно з sh - ніколи не csh чи fish.)

• Поки ви дотримуєтесь shлише функцій, ви можете (і, мабуть, навіть повинні) використовувати, #!/bin/shі сценарій повинен працювати добре, незалежно від того, що це оболонка.

• Якщо ви почнете використовувати спеціальні для bash функції (наприклад, масиви), вам слід спеціально подати запит на bash - тому що, навіть якщо /bin/shвже виклик bash у вашій системі, він може бути не у всіх інших системах, і ваш скрипт не працюватиме там. (Те саме, звичайно, стосується і zsh та ksh.) Ви можете використовувати shellcheck для ідентифікації башизмів.

• Навіть якщо сценарій призначений лише для особистого використання, ви можете помітити, що деякі ОС змінюються /bin/shпід час оновлення - наприклад, на Debian він раніше був баш, але пізніше був замінений на дуже мінімальний тире. Сценарії, які використовували башизми, але #!/bin/shраптом зламалися.

Однак:

• Навіть #!/bin/bashне дуже коректно. У різних системах, Баш може жити /usr/binабо /usr/pkg/binабо /usr/local/bin.

• Більш надійний варіант #!/usr/bin/env bash, який використовує $ PATH. (Хоча і envсам інструмент не є строго гарантованим, він /usr/bin/envвсе ще працює в більшості систем, ніж є /bin/bash.)

Використовуйте шебанг, відповідний оболонці, яку ви насправді використовували для розробки та налагодження сценарію. Тобто, якщо ваша оболонка для входу bash, і ви запускаєте свій скрипт як виконуваний у своєму терміналі, використовуйте #!/bin/bash. Не припускайте, що оскільки ви не використовували масиви (або будь- bashяку іншу функцію, яку ви знаєте), ви можете сміливо вибирати будь-яку оболонку, яка вам подобається. Існує багато тонких відмінностей між оболонками ( echo, функції, петлі, ви їх називаєте), які неможливо виявити без належного тестування.

Враховуйте це: якщо ви виходите, #!/bin/bashа ваші користувачі цього не мають, вони побачать чітке повідомлення про помилку, щось подібне

Error: /bin/bash not found

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

Error in script.sh line 123: error parsing token xyz

Це може зайняти години, щоб виправити, і підказки про те, яку оболонку вони мали використовувати, не буде.

Існує не так багато причин, чому ви хочете використовувати іншу оболонку в шебангу. Однією з причин є те, коли використовувана вами оболонка не має широкого поширення. Ще один - отримати продуктивність, shяка значно швидша в деяких системах, і ваш сценарій буде вузьким місцем продуктивності. У цьому випадку ретельно протестуйте свій скрипт із цільовою оболонкою, а потім змініть шебанг.

Ви повинні використовувати будь-коли #! /bin/sh.

Ви не повинні використовувати розширення bash (або zsh, або fish, або ...) у сценарії оболонки ніколи.

Вам слід коли-небудь писати сценарії оболонки, які працюють з будь-якою реалізацією мови оболонки (включаючи всі програми "утиліти", які йдуть разом із самою оболонкою). Сьогодні ви, ймовірно, можете вважати POSIX.1-2001 ( не -2008) авторитетним для того, на що здатні оболонки та утиліти, але майте на увазі, що одного дня вас можуть попросити перенести свій скрипт у спадщину (наприклад, Solaris або AIX), чиї оболонки та комунальні послуги були заморожені приблизно в 1992 році.

Що, серйозно ?!

Так, серйозно.

Ось що: Shell - жахлива мова програмування. Єдине, що це стосується, це те, що /bin/shце єдиний інтерпретатор скриптів, який гарантовано мати кожна установка Unix.

Ось інша річ: деякі ітерації ядра Perl 5 інтерпретатора ( /usr/bin/perl) є більш ймовірно, будуть доступні на випадково обраної установки Unix , ніж (/(usr|opt)(/(local|sfw|pkg)?)?/bin/bashце. Інші хороші мови сценаріїв (Python, Ruby, node.js тощо) - я навіть включаю PHP і Tcl до цієї категорії, якщо порівнювати з оболонкою) також приблизно доступні як bash та інші розширені оболонки.

Тому, якщо у вас є можливість написання bash-скрипту, ви можете використовувати мову програмування, яка не є страшною.

Тепер, прості скрипти оболонки, такі, що просто запускають кілька програм в послідовності з завдання Cron або щось подібне, немає нічого поганого в тому, щоб залишити їх як скрипти оболонки. Але прості сценарії оболонки не потребують масивів чи функцій чи [[навіть. І ви повинні писати складні сценарії оболонки лише тоді, коли у вас немає іншого вибору. Наприклад, сценарії автозапуску, як правило, все ще є сценаріями оболонки. Але ці сценарії повинні працювати на кожному втіленні, /bin/shщо стосується програми, яка налаштована. а це означає, що вони не можуть використовувати будь-які розширення. Напевно, вам не доведеться піклуватися про старі власні Unixes в наші дні, але вам, мабуть, слід подбати про поточні BSD з відкритим кодом, деякі з яких не встановлюютьсяbashза замовчуванням та вбудовані середовища, які дають лише мінімальний оболонку та busybox.

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

Як правило, якщо час важливіший за функціональність, ви скористаєтеся швидшою оболонкою. sh часто псевдонімується на тире і, як правило, використовується для виконання завдань cron або пакетних операцій, де кожна (нано) секунда враховується.

Щоб бути ще коротшим, використовуйте, shякщо портативність у більшості систем є найважливішою, і bashякщо ви хочете використовувати деякі його особливості, наприклад масиви, якщо версія bash підтримує її.

• sh (для більшості випадків), bash, якщо спеціально потрібно (або ksh, або будь-що інше)

Найбезпечніший шлях. коли важко закодовано, буде / usr / bin /, shellOfChoiceале новим умовою я намагаюся користуватися завжди зараз - оскільки "місця за замовчуванням" через зміну PATH може змінитися:

#! / usr / bin / env sh або
#! / usr / bin / env bash
або, наприклад, скрипти perl
#! / usr / bin / env perl -w

Звичайно, коли у вас є привід для того, щоб сценарій НІКОЛИ не приймав автоматично новий PATH, тоді продовжуйте його жорстко кодувати - і тоді / usr / bin / щось має бути найбільш вірогідним шляхом для використання.