Если это скрипт, просто вызовите скрипт как
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/bash
as /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
.