Locația programuluiEdit
Shebang-urile trebuie să precizeze căile de acces absolute (sau căile de acces relative la directorul de lucru curent) către executabilele sistemului; acest lucru poate cauza probleme pe sistemele care au o dispunere nestandardizată a sistemului de fișiere. Chiar și atunci când sistemele au căi de acces destul de standard, este foarte posibil ca variantele aceluiași sistem de operare să aibă locații diferite pentru interpretul dorit. Python, de exemplu, ar putea fi în /usr/bin/python3, /usr/local/bin/python3, sau chiar ceva de genul /home/nume utilizator/bin/python3 dacă este instalat de un utilizator obișnuit.
O problemă similară există pentru shell-ul POSIX, deoarece POSIX a cerut doar ca numele său să fie sh, dar nu a impus o cale. O valoare comună este /bin/sh, dar unele sisteme, cum ar fi Solaris, au shell-ul compatibil POSIX la /usr/xpg4/bin/sh. În multe sisteme Linux, /bin/sh este o legătură hard sau simbolică către /bin/bash, shell-ul Bourne Again (BASH). Utilizarea unei sintaxe specifice BASH în timp ce se menține un shebang care indică spre sh nu este, de asemenea, portabilă.
Din acest motiv, uneori este necesară editarea liniei shebang după ce se copiază un script de pe un calculator pe altul, deoarece calea care a fost codificată în script poate să nu se aplice pe o nouă mașină, în funcție de consecvența convenției din trecut de plasare a interpretorului. Din acest motiv și pentru că POSIX nu standardizează numele căilor de acces, POSIX nu standardizează această caracteristică. Instrumentul GNU Autoconf poate testa suportul de sistem cu ajutorul macroului AC_SYS_INTERPRETER.
De multe ori, programul /usr/bin/env poate fi utilizat pentru a ocoli această limitare prin introducerea unui nivel de indirecție. #! este urmat de /usr/bin/env, urmat de comanda dorită fără calea completă, ca în acest exemplu:
#!/usr/bin/env sh
Acest lucru funcționează de cele mai multe ori pentru că calea /usr/bin/env este folosită în mod obișnuit pentru utilitarul env,și invocă primul sh găsit în $PATH al utilizatorului, de obicei /bin/sh.
Acest lucru are încă unele probleme de portabilitate cu OpenServer 5.0.6 și Unicos 9.0.2 care au doar /bin/env și nu /usr/bin/env.
Interpretarea caracterelorEdit
O altă problemă de portabilitate este interpretarea argumentelor comenzii. unele sisteme, inclusiv Linux, nu separă argumentele; de exemplu, atunci când se execută scriptul cu prima linie de genul,
#!/usr/bin/env python3 -c
tot textul de după primul spațiu este tratat ca un singur argument, adică python3 -c va fi transmis ca un singur argument către /usr/bin/env, în loc de două argumente. Cygwin se comportă, de asemenea, în acest fel.
Invocările complexe ale interpretului sunt posibile prin utilizarea unui wrapper suplimentar. FreeBSD 6.0 (2005) a introdus o opțiune -S în env-ul său, deoarece a schimbat comportamentul de citire a shebang-reading la non-splitting. Această opțiune îi spune lui env să divizeze el însuși șirul de caractere. Utilitarul GNU env începând cu coreutil 8.30 (2018) include, de asemenea, această funcție. Deși utilizarea acestei opțiuni atenuează problema portabilității la capătul kernelului cu divizarea, ea adaugă cerința ca env să suporte această extensie particulară.
O altă problemă este reprezentată de scripturile care conțin un caracter de revenire la cărucior imediat după linia shebang, poate ca urmare a faptului că au fost editate pe un sistem care utilizează pauze de linie DOS, cum ar fi Microsoft Windows. Unele sisteme interpretează caracterul de revenire la cărucior ca parte a comenzii de interpretare, rezultând un mesaj de eroare.
Număr magicEdit
Shebang-ul este de fapt o instanță lizibilă de către om a unui număr magic din fișierul executabil, șirul de octeți magic fiind 0x23 0x21, codificarea cu două caractere în ASCII a lui #!!!. Acest număr magic este detectat de familia de funcții „exec”, care determină dacă un fișier este un script sau un binar executabil. Prezența shebang-ului va duce la executarea executabilului specificat, de obicei un interpretor pentru limbajul scriptului. S-a afirmat că unele versiuni vechi de Unix se așteaptă ca shebang-ul normal să fie urmat de un spațiu și de o bară oblică (#! /), dar se pare că acest lucru nu este adevărat; mai degrabă, spațiile goale după shebang au fost permise în mod tradițional și, uneori, documentate cu un spațiu (a se vedea e-mailul din 1980 în secțiunea Istoric de mai jos).
Caracterele shebang sunt reprezentate de aceiași doi octeți în codificările ASCII extinse, inclusiv UTF-8, care este utilizat în mod obișnuit pentru scripturi și alte fișiere text pe sistemele actuale de tip Unix. Cu toate acestea, fișierele UTF-8 pot începe cu marca opțională de ordine a octeților (BOM); dacă funcția „exec” detectează în mod specific octeții 0x23 și 0x21, atunci prezența BOM (0xEF 0xBB 0xBF) înainte de shebang va împiedica executarea interpretului de script. Unele autorități recomandă să nu se utilizeze marcajul de ordine a octeților în scripturile POSIX (de tip Unix), din acest motiv și din considerente mai largi de interoperabilitate și filosofice. În plus, un marcaj de ordine a octeților nu este necesar în UTF-8, deoarece această codificare nu are probleme de endianitate; servește doar pentru a identifica codificarea ca fiind UTF-8.
.