Program locationEdit
Shebang はシステム実行ファイルへの絶対パス (または現在の作業ディレクトリからの相対パス) を指定しなければなりませんが、これは標準外のファイルシステムのレイアウトを持つシステムで問題を引き起こすことがあります。 システムがかなり標準的なパスを持っている場合でも、同じオペレーティングシステムのバリエーションが、目的のインタープリタのために異なる場所を持つことはかなり可能です。 例えば Python は /usr/bin/python3 や /usr/local/bin/python3 にあるかもしれませんし、普通のユーザーによってインストールされた場合には /home/username/bin/python3 のようなものでさえあるかもしれません。 一般的な値は /bin/sh ですが、Solaris のようなシステムでは POSIX 互換のシェルが /usr/xpg4/bin/sh にあります。 多くのLinuxシステムでは、/bin/shはBourne Againシェル(BASH)である/bin/bashへのハードリンクまたはシンボリックリンクになっています。 sh を指す shebang を維持しながら bash 固有の構文を使用することも移植性がありません。
このため、スクリプトにコード化されたパスは、インタプリタの配置に関する過去の規則の一貫性によっては、新しいマシンで適用できないことがあるので、あるコンピューターから別のコンピューターにスクリプトをコピーした後に shebang 行を編集することが必要になることがあります。 このような理由と、POSIXはパス名を標準化していないため、POSIXはこの機能を標準化していない。 GNU Autoconf ツールはマクロ AC_SYS_INTERPRETER でシステムのサポートをテストできます。
しばしば、プログラム /usr/bin/env を使用して、間接的なレベルを導入することにより、この制限を回避することができます。 #!
の後に /usr/bin/env を続け、その後にフルパスなしで目的のコマンドを続けます。
#!/usr/bin/env sh
これは、パス /usr/bin/env が env ユーティリティによく使われており、ユーザーの $PATH で見つかった最初の sh、通常は /bin/sh を呼び出すため、ほとんど動作します。
これは、/bin/env のみで /usr/bin/env を持たない OpenServer 5.0.6 と Unicos 9.0.2 ではまだいくつかの移植性の問題があります。
Character interpretationEdit
Another portability problem is the interpretation of the command arguments.If you run the script with the first line like,
#!/usr/bin/env python3 -c
all text after the first space is treated as a single argument, as python3 -c
will be passed as one argument to /usr/bin/env, instead to two arguments.(Linuxなどいくつかのシステムでは引数は分割されない。). Cygwin もこのように動作します。
複雑なインタプリタの呼び出しは、追加のラッパーを使用することで可能となります。 FreeBSD 6.0 (2005) では、shebang-reading の挙動を非分割に変更したため、 env に -S オプションが導入されました。 このオプションはenvに対して、文字列そのものを分割するように指示します。 coreutil 8.30(2018)以降のGNU envユーティリティもこの機能を搭載しています。 このオプションを使用すると、分割によるカーネル側の移植性の問題は軽減されますが、env がこの特定の拡張をサポートするという要件が追加されます。
別の問題は、おそらく Microsoft Windows などの DOS 改行を使用するシステムで編集された結果、shibang 行の直後に復帰文字が含まれているスクリプトにあります。
Magic numberEdit
shebang は、実際には実行ファイル内のマジックナンバーの人間が読めるインスタンスで、マジックバイト列は 0x23 0x21 で、ASCII の 2 文字エンコーディングで #! このマジックナンバーは、ファイルがスクリプトか実行可能なバイナリかを判断する「exec」関数群によって検出されます。 shebangが存在すると、指定された実行ファイル(通常はスクリプトの言語のインタプリタ)が実行されます。 古いバージョンの Unix では、通常の shebang の後にスペースとスラッシュ (#! /
) が付くとされているが、これは事実ではないようである。むしろ、shebang の後の空白は伝統的に認められており、時にはスペースと共に文書化されている (以下の歴史セクションの 1980 年の電子メールを参照).
shibang 文字は、現在の Unix 系システムでスクリプトやその他のテキストファイルによく使われている UTF-8 を含む拡張 ASCII エンコーディングでは、同じ 2 バイトで表されます。 しかし、UTF-8ファイルはオプションのバイトオーダーマーク(BOM)で始まることがあります。もし「exec」関数が特に0x23と0x21のバイトを検出するなら、sebangの前にBOM(0xEF 0xBB 0xBF)があるとスクリプトインタプリタの実行を妨げることになります。 この理由と、より広い相互運用性と哲学的な懸念から、POSIX(Unixライク)スクリプトでバイトオーダーマークを使用しないことを推奨する当局者もいます。 さらに、エンディアンの問題がない UTF-8 では、バイトオーダマークは必要ありません。