Если это скрипт, просто вызовите скрипт как
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того, что были более быстрой и более тонкой реализацией POSIX /bin/sh(то есть она придерживается стандарта POSIX для того, как Unix-подобные утилиты операционной системы и ОС должны вести себя и реализовать некоторые из их внутренних), и из-за соображений переносимости. Я настоятельно рекомендую прочитать ответ Жиля, а также исторические заметки о том, как это /bin/dashпроизошло. Что касается совместимости, сценарии, написанные для dashиспользования функций POSIX, будут работать с bashидеальной оболочкой по умолчанию. Обычно, наоборот, вызывает проблемы -bashимеет функции, которые не требуются /bin/sh, такие как <<<синтаксис или массивы.
Кроме того, рассматриваемая команда, вероятно, написана с учетом RHEL или CentOS, которая использует /bin/bashсимволическую ссылку на /bin/sh, и предлагает две вещи: они, вероятно, нацелены на конкретную ОС и не придерживаются принципов POSIX. В этом случае было бы также неплохо проверить, что еще требуется команде, поскольку, если она действительно написана для другой ОС, вы можете столкнуться с большим количеством проблем, чем просто повторное связывание /bin/sh.