If it's a script, just call the script as
bash scriptname.sh
No need to change links at all.
For compiled executable you can go 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
And then run your program or sudo chroot rootfs /yourprogram
However, in practice there is no reason why you can't use /bin/bash
as a symlink to /bin/sh
. In fact, prior to version 6.10 Ubuntu was using /bin/bash
as /bin/sh
, and then they switched due to /bin/sh
being a much faster, leaner implementation of POSIX /bin/sh
(that is, it adheres to the POSIX standard for how Unix-like operating system utilities and OS should behave and implement some of their internals), and due to portability reasons. I strongly recommend reading Gilles' answer as well for historical notes on how /bin/dash
came about. As for compatibility, scripts written for dash
using POSIX features will run with bash
being a default shell perfectly fine. Usually, it's the other way around that causes problems - bash
has features that aren't required by /bin/sh
, like the <<<
syntax or arrays.
Additionally, the command in question is probably written with RHEL or CentOS in mind, which does use /bin/bash
as a symlink to /bin/sh
, suggests two things: they probably targeted specific OS and didn't adhere to POSIX principles. In that case, it would also be a good idea to check what other things the command requires, since if it's really written with another OS in mind, you might run into more problems than just re-linking /bin/sh
.
/bin/sh
isbash
is a bug, and it causes actual problems (as you're finding out). If no one complains, it may never get changed. – marcelm Sep 11 '18 at 22:38/bin/sh
is actually symlink tobash
. In fact, without naming names, I do know quite a large engineering company that does it this way. Not POSIX compliant, but then again they explicitly state they only support RHEL. – Sergiy Kolodyazhnyy Sep 12 '18 at 00:40