Lokalizacja programuEdit
Shebangi muszą określać bezwzględne ścieżki (lub ścieżki względem bieżącego katalogu roboczego) do systemowych plików wykonywalnych; może to powodować problemy w systemach, które mają niestandardowy układ systemu plików. Nawet jeśli systemy mają dość standardowe ścieżki, jest całkiem możliwe, że warianty tego samego systemu operacyjnego mają różne lokalizacje dla pożądanego interpretera. Python, na przykład, może znajdować się w /usr/bin/python3, /usr/local/bin/python3, lub nawet w czymś takim jak /home/username/bin/python3, jeśli jest zainstalowany przez zwykłego użytkownika.
Podobny problem istnieje dla powłoki POSIX, gdyż POSIX wymagał jedynie, by jej nazwa brzmiała sh, ale nie wymagał ścieżki. Powszechną wartością jest /bin/sh, ale niektóre systemy, takie jak Solaris, mają powłokę zgodną z POSIX-em w /usr/xpg4/bin/sh. W wielu systemach linuksowych, /bin/sh jest twardym lub symbolicznym odnośnikiem do /bin/bash, powłoki Bourne Again (BASH). Używanie składni specyficznej dla bash podczas utrzymywania shebangu wskazującego na sh również nie jest przenośne.
Z tego powodu czasami wymagana jest edycja linii shebang po skopiowaniu skryptu z jednego komputera na drugi, ponieważ ścieżka, która została zakodowana w skrypcie może nie mieć zastosowania na nowej maszynie, w zależności od spójności w przeszłej konwencji umieszczania interpretera. Z tego powodu oraz dlatego, że POSIX nie standaryzuje nazw ścieżek, POSIX nie standaryzuje tej funkcji. Narzędzie GNU Autoconf może testować obsługę systemu za pomocą makra AC_SYS_INTERPRETER.
Często program /usr/bin/env może być użyty do obejścia tego ograniczenia przez wprowadzenie poziomu pośrednictwa. #! po którym następuje /usr/bin/env, a po nim żądane polecenie bez pełnej ścieżki, jak w tym przykładzie:
#!/usr/bin/env sh
To przeważnie działa, ponieważ ścieżka /usr/bin/env jest powszechnie używana dla narzędzia env, i wywołuje pierwszego sh znalezionego w $PATH użytkownika, zwykle /bin/sh.
To wciąż ma pewne problemy z przenośnością z OpenServer 5.0.6 i Unicos 9.0.2, które mają tylko /bin/env, a nie /usr/bin/env.
Interpretacja znakówEdit
Innym problemem przenośności jest interpretacja argumentów poleceń.Niektóre systemy, w tym Linux, nie rozdzielają argumentów; na przykład, gdy uruchamiamy skrypt z pierwszym wierszem jak,
#!/usr/bin/env python3 -c
cały tekst po pierwszej spacji jest traktowany jako pojedynczy argument, czyli python3 -c zostanie przekazany jako jeden argument do /usr/bin/env, a nie dwa argumenty. Cygwin również zachowuje się w ten sposób.
Kompleksowe wywołania interpretera są możliwe dzięki użyciu dodatkowego wrappera. FreeBSD 6.0 (2005) wprowadził opcję -S do swojego env, gdy zmienił zachowanie odczytu shebang na nie-rozdzielanie. Opcja ta mówi env, by sam dokonał podziału łańcucha. Narzędzie GNU env od wersji coreutil 8.30 (2018) również zawiera tę funkcję. Chociaż użycie tej opcji łagodzi problem przenośności po stronie jądra z dzieleniem, dodaje wymóg, że env obsługuje to konkretne rozszerzenie.
Innym problemem są skrypty zawierające znak powrotu karetki bezpośrednio po linii shebang, być może w wyniku edycji w systemie, który używa DOS-owych podziałów wiersza, takich jak Microsoft Windows. Niektóre systemy interpretują znak powrotu karetki jako część polecenia interpretera, co skutkuje komunikatem o błędzie.
Magiczna liczbaEdit
Shebang jest w rzeczywistości czytelną dla człowieka instancją magicznej liczby w pliku wykonywalnym, magiczny ciąg bajtów to 0x23 0x21, dwuznakowe kodowanie w ASCII znaku #! Ta magiczna liczba jest wykrywana przez funkcje z rodziny „exec”, które określają, czy plik jest skryptem czy wykonywalną binarką. Obecność shebangu spowoduje wykonanie określonego pliku wykonywalnego, zwykle interpretera języka skryptu. Twierdzi się, że niektóre stare wersje Uniksa oczekują, że po normalnym shebangu będzie następować spacja i ukośnik (#! /), ale wydaje się to nieprawdą; raczej puste miejsca po shebangu były tradycyjnie dozwolone, a czasem dokumentowane spacją (zobacz email z 1980 roku w sekcji historycznej poniżej).
Znaki shebang są reprezentowane przez te same dwa bajty w rozszerzonych kodowaniach ASCII, w tym UTF-8, który jest powszechnie używany do skryptów i innych plików tekstowych na obecnych systemach uniksopodobnych. Jednakże, pliki UTF-8 mogą zaczynać się od opcjonalnego znaku kolejności bajtów (BOM); jeśli funkcja „exec” specjalnie wykryje bajty 0x23 i 0x21, to obecność BOM (0xEF 0xBB 0xBF) przed shebangiem uniemożliwi wykonanie interpretera skryptu. Niektóre autorytety zalecają nie używać znaku kolejności bajtów w skryptach POSIX (uniksopodobnych) z tego powodu, a także z powodu szerszej interoperacyjności i problemów filozoficznych. Dodatkowo, znak kolejności bajtów nie jest konieczny w UTF-8, ponieważ to kodowanie nie ma problemów z endianness; służy on tylko do identyfikacji kodowania jako UTF-8.