Program locationEdit
A shebangeknek abszolút elérési utakat (vagy az aktuális munkakönyvtárhoz viszonyított elérési utakat) kell megadniuk a rendszer futtatható állományaihoz; ez problémákat okozhat olyan rendszereken, amelyek nem szabványos fájlrendszer elrendezéssel rendelkeznek. Még ha a rendszerek meglehetősen szabványos elérési utakkal rendelkeznek is, könnyen előfordulhat, hogy ugyanannak az operációs rendszernek a változatai eltérő helyen tárolják a kívánt interpretereket. A Python például lehet a /usr/bin/python3, a /usr/local/bin/python3, vagy akár a /home/felhasználónév/bin/python3, ha egy közönséges felhasználó telepítette.
A POSIX shell esetében is hasonló probléma áll fenn, mivel a POSIX csak a sh nevet írta elő, de nem írta elő az elérési utat. Az általános érték a /bin/sh, de néhány rendszeren, például a Solarison a POSIX-kompatibilis héj a /usr/xpg4/bin/sh címen található. Sok Linux rendszerben a /bin/sh egy kemény vagy szimbolikus link a /bin/bash, a Bourne Again shell (BASH) parancsértelmezőhöz. A bash-specifikus szintaxis használata a sh-re mutató shebang fenntartása mellett szintén nem hordozható.
Emiatt néha szükséges a shebang sor szerkesztése egy szkript egyik számítógépről a másikra történő másolása után, mert a szkriptbe kódolt elérési útvonal nem biztos, hogy az új gépen is érvényes, attól függően, hogy az interpreter elhelyezésének korábbi konvenciói következetesek voltak-e. A szkriptet az interpreter elhelyezésének korábbi konvencióitól függően kell módosítani. Emiatt, és mivel a POSIX nem szabványosítja az elérési utak nevét, a POSIX nem szabványosítja ezt a funkciót. A GNU Autoconf eszköz az AC_SYS_INTERPRETER.
makróval tudja tesztelni a rendszer támogatását.
A /usr/bin/env programmal gyakran megkerülhető ez a korlátozás egy indirekciós szint bevezetésével. #! után az /usr/bin/env, majd a kívánt parancs következik a teljes elérési útvonal nélkül, mint ebben a példában:
#!/usr/bin/env sh
Ez többnyire azért működik, mert az /usr/bin/env elérési útvonalat általában az env segédprogramra használják,és a felhasználó $PATH-jában található első sh-t hívja meg, jellemzően a /bin/sh-t. Ez a program a felhasználó $PATH-jában található első sh-t hívja meg.
Ez még mindig hordozhatósági problémákat okoz az OpenServer 5.0.6 és az Unicos 9.0.2 esetében, ahol csak /bin/env van és nincs /usr/bin/env.
KarakterértelmezésSzerkesztés
Egy másik hordozhatósági probléma a parancs argumentumainak értelmezése.Egyes rendszerek, beleértve a Linuxot is, nem osztják szét az argumentumokat; például, ha a szkriptet az első sorral futtatjuk, mint,
#!/usr/bin/env python3 -c
az első szóköz utáni minden szöveget egyetlen argumentumként kezelünk, vagyis python3 -c egyetlen argumentumként kerül átadásra az /usr/bin/env-nek, nem pedig két argumentumként. A Cygwin is így viselkedik.
A komplex értelmezőhívások egy további wrapper használatával lehetségesek. A FreeBSD 6.0 (2005) bevezette az -S opciót az env-be, mivel a shebang-olvasás viselkedését nem osztottra változtatta. Ez az opció azt mondja az env-nek, hogy maga ossza fel a karakterláncot. A GNU env segédprogram a coreutil 8.30 (2018) óta szintén tartalmazza ezt a funkciót. Bár ennek az opciónak a használata enyhíti a hordozhatósági problémát a kernel felől a hasítással kapcsolatban, de növeli azt a követelményt, hogy az env támogassa ezt a bizonyos kiterjesztést.
Egy másik probléma a shebang sor után közvetlenül kocsivissza karaktert tartalmazó szkriptek, talán azért, mert olyan rendszeren szerkesztették, amely DOS-os sortörést használ, mint például a Microsoft Windows. Egyes rendszerek a carriage return karaktert az értelmező parancs részeként értelmezik, ami hibaüzenetet eredményez.
Magic numberEdit
A shebang valójában egy ember által olvasható bűvös szám példánya a futtatható fájlban, a bűvös bájtsorozat 0x23 0x21, ami a #! kétkarakteres ASCII kódolása. Ezt a mágikus számot az “exec” függvénycsalád érzékeli, amely meghatározza, hogy egy fájl egy szkript vagy egy futtatható bináris fájl. A shebang jelenléte a megadott futtatható fájl végrehajtását eredményezi, általában a szkript nyelvének értelmezőjét. Azt állították, hogy a Unix egyes régi verziói elvárják, hogy a normál shebang után szóköz és slash (#! /) következzen, de úgy tűnik, ez nem igaz; inkább a shebang után hagyományosan engedélyezettek az üres betűk, és néha szóközzel dokumentálták (lásd az 1980-as e-mailt a történelem részben alább).
A shebang karaktereket ugyanaz a két bájt képviseli a kiterjesztett ASCII kódolásokban, beleértve az UTF-8 kódolást is, amelyet a jelenlegi Unix-szerű rendszereken a szkriptek és más szövegfájlok esetében gyakran használnak. Az UTF-8 fájlok azonban kezdődhetnek az opcionális byte order markkal (BOM); ha az “exec” függvény kifejezetten a 0x23 és 0x21 bájtokat érzékeli, akkor a shebang előtti BOM (0xEF 0xBB 0xBF) jelenléte megakadályozza a szkriptértelmező végrehajtását. Néhány hatóság javasolja, hogy a POSIX (Unix-szerű) szkriptekben ne használjuk a bájtsorrend-jelölést ebből az okból, valamint szélesebb körű interoperabilitási és filozófiai megfontolásokból. Ezenkívül a bájtsorrend-jelölés nem szükséges az UTF-8 kódolásban, mivel ebben a kódolásban nincsenek endianness problémák; csak arra szolgál, hogy a kódolást UTF-8-ként azonosítsa.