Si es un guión, simplemente llame al guión como
bash scriptname.sh
No es necesario cambiar los enlaces en absoluto.
Para el ejecutable compilado, puede ir a la ruta 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
Y luego ejecuta tu programa o sudo chroot rootfs /yourprogram
Sin embargo, en la práctica no hay ninguna razón por la que no pueda usarlo /bin/bash
como enlace simbólico /bin/sh
. De hecho, antes de la versión 6.10, Ubuntu usaba /bin/bash
como /bin/sh
, y luego cambiaron debido a /bin/sh
una implementación mucho más rápida y ágil de POSIX /bin/sh
(es decir, se adhiere al estándar POSIX sobre cómo deberían comportarse las utilidades del sistema operativo y el sistema operativo tipo Unix y implementar algunos de sus componentes internos), y debido a razones de portabilidad. Recomiendo leer la respuesta de Gilles también para notas históricas sobre cómo /bin/dash
surgió. En cuanto a la compatibilidad, los scripts escritos para dash
usar las funciones POSIX se ejecutarán con bash
un shell predeterminado perfectamente bien. Por lo general, es al revés lo que causa problemas:bash
tiene características que no son necesarias /bin/sh
, como la <<<
sintaxis o las matrices.
Además, el comando en cuestión probablemente esté escrito con RHEL o CentOS en mente, que se utiliza /bin/bash
como un enlace simbólico para /bin/sh
, sugiere dos cosas: probablemente apuntaron a un sistema operativo específico y no se adhirieron a los principios POSIX. En ese caso, también sería una buena idea verificar qué otras cosas requiere el comando, ya que si realmente está escrito con otro sistema operativo en mente, podría tener más problemas que simplemente volver a vincular /bin/sh
.