Localização do programaEditar
Shebangs deve especificar caminhos absolutos (ou caminhos relativos ao diretório de trabalho atual) para os executáveis do sistema; isto pode causar problemas em sistemas que têm um layout de sistema de arquivos não-padrão. Mesmo quando os sistemas têm caminhos razoavelmente padrão, é bem possível que variantes do mesmo sistema operacional tenham localizações diferentes para o intérprete desejado. Python, por exemplo, pode estar em /usr/bin/python3, /usr/local/bin/python3, ou mesmo algo como /home/username/bin/python3 se instalado por um usuário comum.
Existe um problema similar para a shell POSIX, uma vez que o POSIX requeria apenas que seu nome fosse sh, mas não mandou um caminho. Um valor comum é /bin/sh, mas alguns sistemas como o Solaris têm a shell compatível com o POSIX em /usr/xpg4/bin/sh. Em muitos sistemas Linux, o /bin/sh é uma ligação dura ou simbólica ao /bin/bash, a shell Bourne Again (BASH). Usar a sintaxe específica do bash enquanto mantém um shebang apontando para sh também não é portável.
Por causa disso, às vezes é necessário editar a linha do shebang após copiar um script de um computador para outro porque o caminho que foi codificado no script pode não se aplicar em uma nova máquina, dependendo da consistência na convenção passada de colocação do interpretador. Por este motivo, e porque o POSIX não padroniza os nomes dos caminhos, o POSIX não padroniza o recurso. A ferramenta GNU Autoconf pode testar o suporte do sistema com a macro AC_SYS_INTERPRETER.
A maior parte das vezes, o programa /usr/bin/env pode ser usado para contornar esta limitação, introduzindo um nível de indireção. #! é seguido por /usr/bin/env, seguido pelo comando desejado sem caminho completo, como neste exemplo:
#!/usr/bin/env sh
Isto funciona principalmente porque o caminho /usr/bin/env é comumente usado para o utilitário env, e invoca o primeiro sh encontrado no $PATH do usuário, tipicamente o /bin/sh.
Isso ainda tem alguns problemas de portabilidade com OpenServer 5.0.6 e Unicos 9.0.2 que tem apenas /bin/env e nenhum /usr/bin/env.
#!/usr/bin/env python3 -c
todo o texto após o primeiro espaço é tratado como um único argumento, ou seja, python3 -c será passado como um argumento para /usr/bin/env, ao invés de dois argumentos. Cygwin também se comporta desta forma.
A invocações complexas de intérpretes são possíveis através do uso de um invólucro adicional. FreeBSD 6.0 (2005) introduziu uma opção -S ao seu invólucro, pois alterou o comportamento de leitura de shebang- para não-dividir. Esta opção diz ao env para dividir a cadeia em si. O utilitário GNU env desde coreutil 8.30 (2018) também inclui este recurso. Embora o uso desta opção mitigue o problema de portabilidade na extremidade do kernel com a divisão, ele adiciona o requisito de que o env suporta esta extensão em particular.
Outro problema são scripts contendo um caractere de retorno de carruagem imediatamente após a linha de shebang, talvez como resultado de ser editado em um sistema que usa quebras de linha do DOS, como o Microsoft Windows. Alguns sistemas interpretam o caractere de retorno de carruagem como parte do comando interpretador, resultando numa mensagem de erro.
Magic numberEdit
O shebang é na verdade uma instância legível por humanos de um número mágico no ficheiro executável, sendo a string de bytes mágicos 0x23 0x21, a codificação de dois caracteres em ASCII de #! Este número mágico é detectado pela família de funções “exec”, que determina se um arquivo é um script ou um binário executável. A presença do shebang resultará na execução do executável especificado, geralmente um intérprete para a linguagem do script. Tem sido afirmado que algumas versões antigas do Unix esperam que o shebang normal seja seguido por um espaço e uma barra (#! /), mas isto parece ser falso; ao invés disso, espaços em branco após o shebang têm sido tradicionalmente permitidos, e às vezes documentados com um espaço (veja o email de 1980 na seção de história abaixo).
Os caracteres shebang são representados pelos mesmos dois bytes em codificações ASCII estendidas, incluindo UTF-8, que é comumente usado para scripts e outros arquivos de texto em sistemas atuais do tipo Unix. Entretanto, arquivos UTF-8 podem começar com a marca de ordem de byte opcional (BOM); se a função “exec” detectar especificamente os bytes 0x23 e 0x21, então a presença da BOM (0xEF 0xBB 0xBF) antes do shebang impedirá que o interpretador de script seja executado. Algumas autoridades recomendam não usar a marca de ordem de bytes em scripts POSIX (tipo Unix), por este motivo e para uma maior interoperabilidade e preocupações filosóficas. Adicionalmente, uma marca de ordem de byte não é necessária em UTF-8, pois essa codificação não tem problemas de endianness; ela serve apenas para identificar a codificação como UTF-8.