Shell execution context can be tricky. Sitting here now, (mumbly) decades into an IT career, I still don’t full understand why different things work in different situations.
If your very basic script is +x executable, the most basic thing probably works.
run /path/to/script.sh
If you want to not bother with the +x bit, you can use the shell command and reference the script as parameter.
run /bin/sh /path/to/script.sh
If you want pause fixlet processing until the script is done, you need to tell both BigFix and the shell to do that.
wait /bin/sh -c /path/to/script.sh
If you also need the script to run as though it were within a user login session, because reasons(?)
wait /bin/sh -c -l /path/to/script.sh
If you’re down this far, and your script is sufficiently complex, you might find that results are weird in unexpected ways. This might be because your system’s /bin/sh in in fact not sh, but in fact a copy or symlink to /bin/bash. This gets really fun, because bash has hard-coded behaviors which emulate sh when the binary is invoked with the name sh. From the man page:
If bash is invoked with the name sh, it tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well.
For this reason, it might be worthwhile to deliberately invoke bash and simplify your life:
wait /bin/bash -c -l /path/to/script.sh
Sometimes, because reasons(?), even though the BESAgent runs as root and you’re invoking the shell as above, better success happens if you punt and let sudo do it. (Why? I have no freaking idea.)
wait sudo -l /path/to/script.sh
