ProgramplatsEdit
Shebang måste ange absoluta sökvägar (eller sökvägar som är relativa till den aktuella arbetskatalogen) till systemets körbara filer, vilket kan orsaka problem på system som har en icke-standardiserad filsystemlayout. Även när systemen har ganska standardiserade sökvägar är det fullt möjligt att varianter av samma operativsystem har olika platser för den önskade tolken. Python, till exempel, kan finnas i /usr/bin/python3, /usr/local/bin/python3, eller till och med något som /home/username/bin/python3 om det installeras av en vanlig användare.
Ett liknande problem existerar för POSIX-skalet, eftersom POSIX endast krävde att namnet skulle vara sh, men inte krävde en sökväg. Ett vanligt värde är /bin/sh, men vissa system som Solaris har det POSIX-kompatibla skalet på /usr/xpg4/bin/sh. I många Linuxsystem är /bin/sh en hård eller symbolisk länk till /bin/bash, Bourne Again shell (BASH). Att använda bash-specifik syntax samtidigt som man behåller en shebang som pekar på sh är inte heller portabelt.
På grund av detta krävs det ibland att man redigerar shebang-linjen efter att ha kopierat ett skript från en dator till en annan eftersom den sökväg som kodades in i skriptet kanske inte gäller på en ny maskin, beroende på konsekvensen i tidigare konventioner för placering av tolken. Av denna anledning och eftersom POSIX inte standardiserar sökvägsnamn, standardiserar POSIX inte funktionen. Verktyget GNU Autoconf kan testa för systemstöd med makro AC_SYS_INTERPRETER.
Ofta kan programmet /usr/bin/env användas för att kringgå denna begränsning genom att införa en indirekt nivå. #! följs av /usr/bin/env, följt av det önskade kommandot utan fullständig sökväg, som i det här exemplet:
#!/usr/bin/env sh
Detta fungerar för det mesta eftersom sökvägen /usr/bin/env vanligen används för verktyget env, och det anropar den första sh som hittas i användarens $PATH, vanligtvis /bin/sh.
Detta har fortfarande vissa portabilitetsproblem med OpenServer 5.0.6 och Unicos 9.0.2 som endast har /bin/env och inte /usr/bin/env.
TeckentolkningRedigera
Ett annat portabilitetsproblem är tolkningen av kommandots argument.Vissa system, inklusive Linux, delar inte upp argumenten; till exempel, när man kör skriptet med den första raden som,
#!/usr/bin/env python3 -c
behandlas all text efter det första mellanslaget som ett enda argument, det vill säga, python3 -c kommer att skickas som ett argument till /usr/bin/env, istället för två argument. Cygwin beter sig också på detta sätt.
Komplexa tolkaranrop är möjliga genom att använda en extra wrapper. FreeBSD 6.0 (2005) införde ett -S-alternativ till sin env då den ändrade beteendet för shebang-läsning till att inte dela upp. Detta alternativ säger till env att dela strängen själv. GNU env-verktyget sedan coreutil 8.30 (2018) innehåller också den här funktionen. Även om användningen av det här alternativet mildrar portabilitetsproblemet i kärnans ände med splitting, lägger det till kravet att env har stöd för just det här tillägget.
Ett annat problem är skript som innehåller ett vagnreturtecken omedelbart efter shebang-linjen, kanske som ett resultat av att de har redigerats på ett system som använder DOS-linjebrytning, t.ex. Microsoft Windows. Vissa system tolkar vagnreturtecknet som en del av tolkningskommandot, vilket resulterar i ett felmeddelande.
Magiskt nummerRedigera
Shebang är i själva verket en människoläsbar instans av ett magiskt nummer i den körbara filen, där den magiska bytesträngen är 0x23 0x21, ASCII-kodningen med två tecken för #!. Detta magiska nummer upptäcks av funktionerna i ”exec”-familjen, som avgör om en fil är ett skript eller en körbar binär fil. Närvaron av shebang kommer att leda till att den angivna körbara filen exekveras, vanligtvis en tolk för skriptets språk. Det har hävdats att vissa gamla versioner av Unix förväntar sig att den normala shebang ska följas av ett mellanslag och ett snedstreck (#! /), men detta verkar inte vara sant; snarare har blanksteg efter shebang traditionellt varit tillåtet, och ibland dokumenteras det med ett mellanslag (se e-post från 1980 i avsnittet om historia nedan).
Shebang-tecknen representeras av samma två bytes i utökade ASCII-kodningar, inklusive UTF-8, som vanligen används för skript och andra textfiler på aktuella Unix-liknande system. UTF-8-filer kan dock börja med den valfria byteordermarkeringen (BOM); om ”exec”-funktionen specifikt upptäcker bytes 0x23 och 0x21, kommer förekomsten av BOM (0xEF 0xBB 0xBF) före shebang att förhindra att skripttolken exekveras. Vissa auktoriteter rekommenderar att man inte använder byteordermarkeringen i POSIX-skript (Unix-liknande), av denna anledning och av bredare interoperabilitets- och filosofiska skäl. Dessutom är en byteordermarkering inte nödvändig i UTF-8, eftersom denna kodning inte har några problem med endianness; den tjänar endast till att identifiera kodningen som UTF-8.