シェバン（Unix）

ファイル拡張子と解釈アプリケーション間のグローバル関連付けリストを使用する方法と比較すると、インタプリタディレクティブ方式では、システム全体で認識されていないインタプリタを、管理者権限なしで使用できます。また、ファイル名拡張子の名前空間（1つのファイル拡張子が複数のファイルタイプを参照する）をオーバーロードすることなく、インタプリタを個別に選択でき、他のプログラムによる呼び出し構文を変更することなく、スクリプトの実装言語を変更できます。スクリプト自体が使用するインタプリタを指定するため、スクリプトの呼び出し側は実装言語を知る必要はありません。

シェバンでは、システム実行可能ファイルへの絶対パス（または現在の作業ディレクトリからの相対パス）を指定する必要があります。これは、ファイルシステムのレイアウトが標準的でないシステムでは問題を引き起こす可能性があります。システムが比較的標準的なパスを使用している場合でも、同じオペレーティングシステムのバリアントによって、目的のインタープリタの場所が異なることは十分にあり得ます。たとえば、Python は、 /usr/bin/python3、/usr/local/bin/python3、または一般ユーザーがインストールした場合は/home/username/bin/python3のような場所に存在する可能性があります。

POSIX シェルにも同様の問題があります。POSIX では名前がshであることのみを要求し、パスは義務付けていませんでした。一般的な値は/bin/shですが、Solaris などの一部のシステムでは、POSIX 互換シェルが/usr/xpg4/bin/shにあります。^{[ 13 ]}多くのLinuxシステムでは、/bin/shはBourne Again シェル(BASH) である/bin/bashへのハード リンクまたはシンボリック リンクです。shを指す shebang を維持しながら bash 固有の構文を使用することも移植性がありません。^{[ 14 ]}

このため、スクリプトに記述されたパスが、過去のインタープリタ配置の慣例の一貫性によっては新しいマシンに適用されない可能性があるため、スクリプトをあるコンピュータから別のコンピュータにコピーした後、シェバン行を編集する必要がある場合があります。この理由と、POSIX がパス名を標準化していないため、POSIXはこの機能を標準化していません。^{[ 15 ]} GNU Autoconfツールは、 マクロ AC_SYS_INTERPRETER を使用してシステムサポートをテストできます。^{[ 16 ]}

多くの場合、 /usr/bin/envプログラムを使用して間接参照を導入することで、この制限を回避できます。例のように、 /usr/bin/envの後に、フルパスを指定せずに目的のコマンドが続きます。#!

#!/usr/bin/env sh

これは、/usr/bin/envパスがenvユーティリティによく使用され、ユーザーの$PATHで最初に見つかったsh (通常は/bin/sh)が呼び出されるため、大抵はうまくいきます。

この特定の例（shを使用）は、用途が限られています。/bin/sh も/ usr /bin/envも普遍的ではなく、どちらも存在しないデバイスが同程度存在します。さらに広く言えば、#!/usr/bin/env を任意のスクリプトに使用すると、 /bin/envしかなく/usr/bin/envがないOpenServer 5.0.6 およびUnicos 9.0.2との間で移植性の問題がいくつか発生します。

#!/usr/bin/envを使用すると、実行時間接参照が発生し、システムセキュリティが低下する可能性があります。そのため、一部の評論家はパッケージソフトウェアでの使用を推奨せず^{[ 17 ]}、「教育的な例」にのみ使用することを推奨しています。

コマンド引数はプラットフォームによって分割方法が異なります。一部のシステムでは引数が分割されません。たとえば、最初の行でスクリプトを実行すると、

#!/usr/bin/env python3 -c

最初のスペース以降のすべてのテキストは単一の引数として扱われ、つまり、2 つの引数ではなく、 1 つの引数として/usr/bin/envpython3 -cに渡されます。このようなシステムには、Linux ^{[ 18 ] [ 19 ]}やCygwinなどがあります。

別のアプローチとしては、ラッパーの使用があります。FreeBSD 6.0 (2005) では、シェバン読み取り動作を分割しないように変更したため、env に -S オプションが導入されました。このオプションは、env に文字列自体を分割するように指示します。 [ 20 ] coreutils ^{8.30 ( 2018} )以降のGNU envユーティリティにもこの機能が含まれています。^{[ 21 ]}このオプションを使用すると、カーネル側での分割による移植性の問題が軽減されますが、env がこの特定の拡張機能をサポートしているという要件が追加されます。

もう1つの問題は、Microsoft WindowsなどのDOS改行を使用するシステムで編集された結果、シェバン行の直後にキャリッジリターン文字を含むスクリプトです。一部のシステムでは、キャリッジリターン文字をインタープリタコマンドの一部として解釈し、エラーメッセージを表示します。^{[ 22 ]}

シェバンは実際には実行可能ファイル内のマジックナンバーの人間が読めるインスタンスであり、マジックバイト列は0x23 0x21で、 #!の2 文字のASCIIエンコードです。このマジックナンバーは、ファイルがスクリプトか実行可能バイナリかを判断する「 exec 」関数ファミリーによって検出されます。シェバンが存在すると、指定された実行可能ファイル（通常はスクリプトの言語のインタプリタ）が実行されます。古いバージョンの Unix では、通常のシェバンの後にスペースとスラッシュ ( ) が続くことが想定されているという主張^{[ 23 ]}がありますが、これは正しくないようです。^{[ 11 ]}むしろ、シェバンの後に空白が伝統的に許可されており、以下の1980 年の歴史的な電子メールで説明されているように、スペースで文書化されることもあります。#! /

シェバン文字は、現在の Unix ライクなシステムでスクリプトやその他のテキストファイルによく使用されるUTF-8を含む拡張 ASCIIエンコーディングでは同じ 2 バイトで表されます。ただし、UTF-8 ファイルはオプションのバイトオーダーマーク(BOM) で始まる場合があります。「exec」関数がバイト0x23と0x21を明示的に検出した場合、シェバンの前に BOM ( 0xEF 0xBB 0xBF ) が存在すると、スクリプト インタプリタの実行が妨げられます。この理由と、より広範な相互運用性および哲学的懸念から、一部の専門家はPOSIX (Unix ライク) スクリプトでバイトオーダーマークを使用しないことを推奨しています^{[ 24 ]。}さらに、UTF-8 エンコーディングにはエンディアンの問題がないため、バイトオーダーマークは UTF-8 では不要です。バイトオーダーマークは、エンコーディングが UTF-8 であることを識別するためだけに使用されます^{[ 24 ] 。}

Unix ライクなシステムの後のバージョンでは、この矛盾は解消されました。デニス・リッチーは1980 年 1 月に、 Unix バージョン 8向けにインタプリタ ディレクティブのカーネル サポートを導入し、次のように説明しました。^{[ 29 ]}

uucp から 1980 年 1 月 10 日木曜日 01:37:58 >dmr から 1980 年 1 月 10 日 木 4:25:49 研究から離れた場所 実行中のファイルがある場合、システムが変更されました マジック文字「#!」で始まり、行の残りの部分は自動的に解釈されます。 実行されるファイルのインタプリタの名前となる。 以前は（そして実際今でも）、砲弾がこうした役割の多くを担っていた。 実行可能モードでテキストファイル上で自動的に実行されました テキストファイル名がコマンドとして入力されたとき。 施設をシステムに組み込むと、次のようになります。 利点。 1) シェルスクリプトを実際の実行可能ファイルに近づける、 なぜなら、それらは「exec」の対象となる可能性があるからです。 2) このようなコマンドの実行中に「ps」を実行すると、 「sh」の代わりに名前が表示されます。 同様に、会計処理も実名に基づいて行われる。 3) シェルスクリプトはset-user-IDで設定できます。[ a ] 4) 代替のシェルを用意しておく方が簡単である。 例えば、バークレーのcshが好きなら、 どのシェルがファイルを解釈するか。 5）これにより、他の通訳者もよりスムーズに業務に溶け込むことができる。 この素晴らしい機会を活用するために、 置く #! /bin/sh シェルスクリプトの最初の行の左端に記述してください。 ! の後に空白があっても構いません。完全なパス名を使用してください（検索は行われません）。 現時点では行全体が16文字に制限されていますが この制限は引き上げられる予定です。

しかし、この機能の作成者はそれに名前を付けませんでした。^{[ 31 ]}

差出人: "Ritchie, Dennis M (Dennis)** CTR **" <dmr@[redacted]> 宛先: <[redacted]@ talisman.org > 日付: 2009 年 11 月 19 日(木) 18:37:37 -0600件名: RE: #!<something>行を何と呼びますか? 正式な名前をつけた記憶がない。 かなり遅い時間に入ってしまったと思う。 UCBのカンファレンスで誰かからそのアイデアを得た。 Berkeley Unix 上で、私はおそらく最初に 実際にインストールするわけではなく、私が思いついたアイデアだった 他の場所から。 名前については、おそらく説明的なものになるでしょう。 「ハッシュバン」は特にイギリス風だが、 いずれにしても、特に愛称を使った記憶はない。 建設のために。 

インタプリタディレクティブのカーネルサポートは他のバージョンのUnixにも広がり、最新の実装の1つはLinuxカーネルソースのfs/binfmt_script.cで見ることができる。^{[ 32 ]}

このメカニズムにより、スクリプトは、通常のコンパイル済みプログラムが使用できるほぼすべてのコンテキストで使用できます。これには、完全なシステムプログラムとして、さらには他のスクリプトのインタプリタとしての使用も含まれます。ただし、注意点として、カーネルサポートの初期バージョンでは、インタプリタディレクティブの長さが約32文字（最初の実装ではわずか16文字）に制限されていたり、ディレクティブ内のパラメータからインタプリタ名を分離できなかったり、その他の不具合があったりしました。さらに、一部の最新システムでは、セキュリティ上の理由から、このメカニズム全体を制限または無効にすることができます（たとえば、多くのシステムでスクリプトのset-user-idサポートが無効になっています）。

なお、カーネルがマジックナンバー「#!」を完全にサポートしているシステムであっても、インタプリタ ディレクティブを持たないスクリプト（通常は実行権限が必要）でも、Bourneシェルの従来のスクリプト処理機能（多くの後継シェルにも依然として搭載されている）のおかげで実行できる場合があります。その場合、スクリプトはユーザーのデフォルトシェルによって解釈されます。