スクリプトの場合は、次のようにスクリプトを呼び出します。
bash scriptname.sh
リンクを変更する必要はまったくありません。
コンパイルされた実行可能ファイルの場合、chrootルートに移動できます。
mkdir rootfs
cp -a /usr rootfs/
cp -a /lib rootfs/
cp -a /lib64 rootfs/
cp /bin/bash rootfs/bin/sh
cp yourprogram rootfs/
sudo chroot rootfs sh
そして、あなたのプログラムを実行するか、 sudo chroot rootfs /yourprogram
ただし、実際には/bin/bash
、へのシンボリックリンクとして使用できない理由はありません/bin/sh
。実際、バージョン6.10より前は、 Ubuntuは/bin/bash
as を使用/bin/sh
し/bin/sh
ていまし/bin/sh
たが、POSIXのはるかに高速で無駄のない実装のために切り替えられました(つまり、UnixのようなオペレーティングシステムユーティリティとOSの動作に関するPOSIX標準に準拠しています。それらの内部の一部を実装する)、および移植性の理由による。どのようにして起こったのかについての歴史的なメモについては、Gillesの回答も読むことを強くお勧めします/bin/dash
。互換性に関しては、dash
POSIX機能を使用するために記述されたスクリプトbash
は、デフォルトのシェルとして完全に問題なく実行されます。通常、問題を引き起こすのはその逆です-bash
には/bin/sh
、<<<
構文や配列など、には不要な機能があります。
さらに、問題のコマンドはおそらくRHELまたはCentOSを念頭に置いて記述されて/bin/bash
おり、へのシンボリックリンクとして使用され、/bin/sh
2つのことを示唆しています。それらはおそらく特定のOSをターゲットとし、POSIXの原則に準拠していません。その場合、コマンドが他に何を必要とするかを確認することもお勧めします。別のOSを念頭に置いて実際に記述されていると、単に再リンクするよりも多くの問題が発生する可能性があるため/bin/sh
です。