（これは苦情ではなく一般的な質問です。これについて良い説明があるかもしれません。）
コンパイルされた実行可能ファイルの場合、オペレーティングシステムが決定するのではなく、インタプリタパスをバイナリにハードコードするのはなぜですか？つまり、インタプリタは実行可能ファイルの形式（ELFなど）やアーキテクチャ（x86-64）から派生してはなりません。
通訳者パスは、次の実行時に表示されますfile /path/to/some-executable。
some-executable: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=acd1829414c2843215bd10ed75a0fe486fce288e, not stripped
インタプリタパス文字列が実際にバイナリに存在するstrings -t x /path/to/some-executable | headことを確認し、バイト0x270：にあるとマークするには、ファイルを270 /lib64/ld-linux-x86-64.so.2チェックするとreadelf -l /path/to/some-executableインタプリタと同じオフセットが表示されます。
答え1
利用可能な属性ELFヘッダ(動的リンカー自体へのポインターは除く)いいえ適切な動的リンカーを決定するのに十分です。動的リンカーはコンパイラが構築されたCライブラリにも接続されているため、たとえばGNU Cライブラリで構築されたLinuxの64ビットx86バイナリmusl 動的リンカーによってロードされると失敗します。:
バイナリ互換性はより制限的ですが、新しいバージョンのmuslでは着実に改善されます。現在、一部のglibcリンク共有ライブラリはmuslを使用してロードできますが、muslを
/lib/ld-linux.so.2。
ダイナミックリンカーの選択は、共有ライブラリの検索方法も制御するため、パスを使用せずにリンカースタイルアルゴリズムを使用して適切なリンカーを見つけない限り、名前だけでダイナミックリンカーを指定することもできません。別のアプローチも可能ですが、カーネルで実装する必要があるため、各バイナリにハードコーディングする方がはるかに簡単です。
答え2
必要な標準パスに従ってインタプリタを指定するか、代わりに/usr/bin/envを使用してください。 'nixシステムではログイン履歴があります。ほとんどのスクリプトの冒頭にあるハッシュバン行を見てください。実際のオペレーティングシステムファイルタイプの概念がないため、予想されるパス、インタプリタ、またはリンカをファイルに配置することは、置き換えられたことのない古い標準ソリューションです。