Another problem with porting Bash scripts is that Bash is not always reliably in the same location. On GNU/Linux systems, it's almost always available in /bin/bash. On other systems, such as FreeBSD, it might instead be in /usr/local/bin/bash.
One way of working around this portability problem is to use a trick with the /usr/bin/env program; using it as a shebang with bash as the argument will find the first bash program in PATH:
#!/usr/bin/env bash
This works well on most systems, but it's not perfect. One subtle problem with it is that it means the bash executable to run the script is chosen at runtime. This means that a user with their own copy of bash installed or with a PATH that points to a different version of bash might experience different behavior from the same script.
If you are distributing your script for other systems in an archive or in a system package, if at all possible, you should specify a fixed path, such as #!/bin/bash, for the correct interpreter either in the packaging process or at build time. For casual sharing of programs, using /usr/bin/env might be good enough, and even if it does not work, your users will be able to see the language you mean the script should run in, and can correct it to point to the right location of the bash program for their system.