Si c'est un script, appelez simplement le script comme
bash scriptname.sh
Pas besoin de changer de liens du tout.
Pour l'exécutable compilé, vous pouvez aller chroot route:
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
Et puis exécutez votre programme ou sudo chroot rootfs /yourprogram
Cependant, dans la pratique, il n'y a aucune raison pour laquelle vous ne pouvez pas l'utiliser /bin/bash
comme lien symbolique vers /bin/sh
. En fait, avant la version 6.10, Ubuntu utilisait /bin/bash
as /bin/sh
, puis ils ont changé en raison d' /bin/sh
une implémentation beaucoup plus rapide et plus légère de POSIX /bin/sh
(c'est-à-dire qu'il respecte la norme POSIX pour la façon dont les utilitaires et les systèmes d'exploitation de type Unix devraient se comporter et implémenter certains de leurs internes), et pour des raisons de portabilité. Je recommande fortement de lire la réponse de Gilles également pour des notes historiques sur la façon dont cela /bin/dash
s'est produit. Quant à la compatibilité, les scripts écrits pour dash
utiliser les fonctionnalités POSIX fonctionneront avec bash
un shell par défaut parfaitement bien. Habituellement, c'est l'inverse qui cause des problèmes -bash
a des fonctionnalités qui ne sont pas requises par /bin/sh
, comme la <<<
syntaxe ou les tableaux.
De plus, la commande en question est probablement écrite en gardant à l'esprit RHEL ou CentOS, qui utilise /bin/bash
un lien symbolique vers /bin/sh
, suggère deux choses: ils ciblaient probablement un système d'exploitation spécifique et n'adhéraient pas aux principes POSIX. Dans ce cas, ce serait également une bonne idée de vérifier les autres éléments requis par la commande, car si elle est vraiment écrite avec un autre système d'exploitation à l'esprit, vous pourriez rencontrer plus de problèmes que la simple reconnexion /bin/sh
.