Шебанг (, також відомий як sha-bang, hashbang, pound-bang або hash-pling) — в комп'ютингу це послідовність із двох символів: знаку решітки (також знаного як шарп) та знаку оклику (#!), розміщена на самому початку файлу скрипту.

Коли текстовий файл, що містить шебанг, використовується як виконувана програма в Unix-подібних операційних системах, механізм завантажувача програм розпізнає решту початкового рядка файлу як директиву інтерпретатора. Завантажувач запускає зазначену програму-інтерпретатор, передаючи їй як аргумент шлях, який був використаний при запуску скрипту, щоб програма могла використовувати цей файл як вхідні дані. Наприклад, якщо скрипт має шлях path/to/script і починається з рядка #! /bin/sh, то завантажувач програм запустить програму /bin/sh, передавши path/to/script як перший аргумент.

Рядок шебангу зазвичай ігнорується самим інтерпретатором, оскільки символ «#» є маркером коментаря у багатьох скриптових мовах; деякі інтерпретатори мов, які не використовують знак решітки для початку коментарів, все одно можуть ігнорувати рядок шебангу, розпізнаючи його призначення.

Синтаксис Форма директиви інтерпретатора шебанг виглядає наступним чином: #! інтерпретатор [необов'язковий-аргумент] де інтерпретатор — це абсолютний шлях до виконуваного файлу. Пробіл між та інтерпретатор є необов'язковим. Перед або після інтерпретатора може бути будь-яка кількість пробілів або символів табуляції. Необов'язковий-аргумент включає будь-які додаткові пробіли до кінця рядка.

У Linux файл, вказаний як інтерпретатор, може бути виконаний, якщо він має права на виконання та є одним із наступного: нативний виконуваний файл, наприклад, бінарний файл у форматі ELF; будь-який тип файлу, для якого інтерпретатор був зареєстрований через механізм binfmt_misc (наприклад, для запуску бінарних файлів Microsoft .exe за допомогою Wine); інший скрипт, що починається з шебангу.

У Linux та Minix інтерпретатор також може бути скриптом. Ланцюжок шебангів та обгорток (wrappers) створює безпосередньо виконуваний файл, який отримує зустрінуті скрипти як параметри у зворотному порядку. Наприклад, якщо файл /bin/A є виконуваним файлом у форматі ELF, файл /bin/B містить шебанг , а файл /bin/C містить шебанг , то виконання файлу /bin/C призведе до виконання , що в кінцевому підсумку перетвориться на .

В операційних системах, похідних від Solaris та Darwin (наприклад, macOS), файл, зазначений як інтерпретатор, повинен бути виконуваним бінарним файлом і не може сам бути скриптом.

Приклади Деякі типові рядки шебангу: #! /bin/sh — виконати файл за допомогою Bourne shell або сумісної оболонки, яка, як передбачається, знаходиться в каталозі /bin. #! /bin/bash — виконати файл за допомогою Bash. #! /usr/bin/pwsh — виконати файл за допомогою PowerShell. #! /usr/bin/env python3 — виконати за допомогою інтерпретатора Python, використовуючи шлях пошуку програм env, щоб знайти його. #! /bin/false — нічого не робити, але повернути ненульовий код виходу, вказуючи на невдачу. Використовується для запобігання автономному виконанню файлу скрипту, призначеного для виконання в певному контексті, наприклад, командою . з sh/bash, source з csh/tcsh, або як файли .profile, .cshrc чи .login.

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

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

Наприклад, розглянемо скрипт, що має початковий рядок #! /bin/sh -x. Його можна викликати просто вказавши шлях до нього, наприклад some/path/to/foo,якщо це дозволено бітами прав доступу exec файлу і деякі параметри, такі як bar та baz:

some/path/to/foo bar baz

У цьому випадку замість нього викликається /bin/sh з параметрами -x, some/path/to/foo, bar та baz, так ніби початкова команда була:

/bin/sh -x some/path/to/foo bar baz

Більшість інтерпретаторів роблять будь-які додаткові аргументи доступними для скрипту. Якщо /bin/sh є POSIX-сумісною оболонкою, то bar та baz представлені скрипту як масив позиційних параметрів "$@", і індивідуально як параметри "$1" та "$2" відповідно.

Оскільки початковий символ # використовується для введення коментарів у мові оболонки POSIX (і в мовах, зрозумілих багатьом іншим інтерпретаторам), весь рядок шебангу ігнорується інтерпретатором. Однак ігнорування рядка шебангу залежить від самого інтерпретатора, і не всі це роблять; тому скрипт, що складається з наступних двох рядків, просто виведе обидва рядки при запуску: #! /bin/cat Hello world!

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

Переносимість

Розташування програми Шебанги повинні вказувати абсолютні шляхи (або шляхи відносно поточного робочого каталогу) до системних виконуваних файлів; це може викликати проблеми на системах, які мають нестандартну структуру файлової системи. Навіть якщо системи мають досить стандартні шляхи, цілком можливо, що варіанти однієї і тієї ж операційної системи мають різні розташування для бажаного інтерпретатора. Python, наприклад, може бути в /usr/bin/python3, /usr/local/bin/python3, або навіть щось на зразок /home/username/bin/python3, якщо встановлений звичайним користувачем.

Подібна проблема існує і для оболонки POSIX, оскільки POSIX вимагає лише, щоб її ім'я було sh, але не вказує шлях. Поширеним значенням є , але деякі системи, такі як Solaris, мають POSIX-сумісну оболонку за адресою /usr/xpg4/bin/sh. У багатьох системах Linux /bin/sh є жорстким або символьним посиланням на /bin/bash, Bash (Bourne Again shell). Використання специфічного синтаксису bash при збереженні шебангу, що вказує на sh, також не є переносимим.

Через це іноді потрібно редагувати рядок shebang після копіювання скрипта з одного комп'ютера на інший, оскільки шлях, який був закодований у скрипті, може не застосовуватися на новій машині, залежно від узгодженості попередніх правил розміщення інтерпретатора. З цієї причини, а також тому, що POSIX не стандартизує імена шляхів, POSIX не стандартизує цю функцію. Інструмент GNU Autoconf може перевірити підтримку системи за допомогою макросу AC_SYS_INTERPRETER.

Часто програма може бути використана для обходу цього обмеження, вводячи рівень непрямої адресації (indirection). супроводжується , за яким слідує бажана команда без повного шляху, як у цьому прикладі: #!/usr/bin/env sh

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

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

Розбиття аргументів Аргументи команд розбиваються по-різному на різних платформах. Деякі системи не розбивають аргументи; наприклад, при запуску скрипту з першим рядком: #!/usr/bin/env python3 -c весь текст після першого пробілу розглядається як один аргумент, тобто буде передано як один аргумент до , а не як два аргументи. До таких систем належать Linux, section "Interpreter scripts" та Cygwin.

Іншим підходом є використання обгортки (wrapper). FreeBSD 6.0 (2005) ввела опцію для своєї утиліти . Ця опція вказує розділити рядок самостійно. Утиліта GNU з пакету coreutils 8.30 (2018) також включає цю функцію. Хоча використання цієї опції зменшує проблему переносимості на стороні ядра через розділення, вона додає вимогу, щоб env підтримував це конкретне розширення.

Інтерпретація символів Іншою проблемою є скрипти, що містять символ повернення каретки відразу після рядка шебангу, можливо, в результаті редагування в системі, яка використовує розриви рядків DOS (Microsoft Windows). Деякі системи інтерпретують символ повернення каретки як частину команди інтерпретатора, що призводить до повідомлення про помилку.

Магічне число Шебанг насправді є зручним для читання людиною екземпляром магічного числа у виконуваному файлі; магічним рядком байтів є , що є двосимвольним кодуванням в ASCII для . Це магічне число виявляється сімейством функцій "exec", які визначають, чи є файл скриптом або виконуваним бінарним файлом. Наявність shebang призведе до виконання зазначеного виконуваного файлу, зазвичай інтерпретатора мови скрипта. Стверджувалося, що деякі старі версії Unix очікують, що після звичайного shebang буде пробіл та похила риска (), але це, схоже, не відповідає дійсності; радше пробіли після shebang традиційно дозволялися, а іноді документувалися з пробілом, як описано в історичному електронному листі 1980 року нижче.

Символи шебангу представлені тими ж двома байтами в кодуваннях розширеного ASCII, включаючи UTF-8, який зазвичай використовується для скриптів у сучасних Unix-подібних системах. Однак файли UTF-8 можуть починатися з необов'язкового маркера послідовності байтів (BOM); якщо функція "exec" конкретно виявляє байти та , то наявність BOM () перед шебангом завадить виконанню інтерпретатора скрипту. Деякі джерела рекомендують не використовувати BOM у скриптах POSIX (Unix-подібних) з цієї причини, а також для ширшої сумісності. Крім того, позначка порядку байтів не є необхідною в UTF-8, оскільки це кодування не має проблем з порядком байтів; вона служить лише для ідентифікації кодування як UTF-8.

Етимологія Назва шебанг (shebang) для характерних двох символів, ймовірно, походить від неточного стягнення слів SHArp bang або haSH bang, посилаючись на дві типові назви цих символів у Unix. Інша теорія щодо sh у shebang полягає в тому, що це походить від оболонки за замовчуванням sh, яка зазвичай викликається за допомогою шебангу. Це використання було актуальним до грудня 1989 року, і ймовірно раніше.

Історія Шебанг був введений Деннісом Рітчі між Виданням 7 та 8 у Bell Laboratories. Його також було додано до релізів BSD від Berkeley's Computer Science Research (присутній у версії 2.8BSD та активований за замовчуванням у версії 4.2BSD). Оскільки Unix 8-го видання AT&T Bell Laboratories не був випущений для широкого загалу, перша широковідома поява цієї функції відбулася в BSD.

Відсутність директиви інтерпретатора, але підтримка скриптів оболонки, очевидна в документації Version 7 Unix 1979 року, що натомість описує функцію оболонки Bourne, де файли з дозволом на виконання обробляються спеціально оболонкою, яка (іноді залежно від початкових символів у скрипті, таких як ":" або "#") створює підоболонку, яка інтерпретує та виконує команди, що містяться у файлі. У цій моделі скрипти поводяться як інші команди, лише якщо їх викликати з оболонки Bourne. Спроба безпосередньо виконати такий файл через власний системний виклик exec() операційної системи зазнає невдачі, що заважає скриптам поводитися однаково як звичайні системні команди.

Вдосконалені скрипти оболонки Version 8 У пізніших версіях Unix-подібних систем цю непослідовність було усунуто. Денніс Рітчі ввів підтримку директив інтерпретатора в ядрі у січні 1980 року для Version 8 Unix з наступним описом:

Від uucp Чт 10 Січ 01:37:58 1980 > Від dmr Чт 10 Січ 04:25:49 1980 віддалено від дослідження