Se for um script, basta chamá-lo como
bash scriptname.sh
Não há necessidade de alterar os links.
Para executável compilado, você pode seguir a rota 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
E então execute seu programa ou sudo chroot rootfs /yourprogram
No entanto, na prática, não há razão para que você não possa usar /bin/bash
como link simbólico para /bin/sh
. De fato, antes da versão 6.10, o Ubuntu estava usando /bin/bash
como /bin/sh
e, em seguida, eles mudaram devido a /bin/sh
uma implementação muito mais rápida e mais enxuta do POSIX /bin/sh
(ou seja, segue o padrão POSIX de como os utilitários de sistema operacional e o sistema operacional semelhantes ao Unix devem se comportar e implementar alguns de seus internos) e por motivos de portabilidade. Eu recomendo fortemente a leitura da resposta de Gilles , bem como notas históricas sobre como isso /bin/dash
aconteceu. Quanto à compatibilidade, os scripts escritos para dash
usar os recursos do POSIX serão executados bash
como um shell padrão perfeitamente adequado. Geralmente, é o contrário que causa problemas -bash
possui recursos que não são necessários /bin/sh
, como <<<
sintaxe ou matrizes.
Além disso, o comando em questão provavelmente é escrito com o RHEL ou o CentOS em mente, que usa /bin/bash
como um link simbólico para /bin/sh
, sugere duas coisas: eles provavelmente foram direcionados ao SO específico e não aderiram aos princípios do POSIX. Nesse caso, também seria uma boa ideia verificar quais outras coisas o comando exige, pois se ele realmente foi escrito com outro sistema operacional em mente, você pode ter mais problemas do que apenas se reconectar /bin/sh
.