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