You need to run a bash script on several machines, but bash is not always in the same place.
Use the /usr/bin/env command in the shebang line, as in #!/usr/bin/env bash.
If your system doesn’t have env in /usr/bin, ask your system administrator to install it, move it, or create a symbolic link because this is the required location.
For example, Red Hat inexplicably uses /bin/env, but they at least create a symlink to the correct location.
You could also create symbolic links for bash itself, but using env is the canonical
and correct solution.
env’s purpose is to “run a program in a modified environment,” but since it will
search the path for the command it is given to run, it works very well for this use.
You may be tempted to use #!/bin/sh instead.
Don’t. If you are using bash-specific features in your script, they will not work on machines that do not use bash in Bourne shell mode for /bin/sh (e.g., BSD, Solaris, Ubuntu 6.10+).
And even if you aren’t using bash-specific features now, you may forget about that in the future.
If you are committed to using only POSIX features, by all means use #!/bin/sh but
otherwise be specific.
You may sometimes see a space between #! and /bin/whatever.
Historically there were some systems that required the space, though in practice we haven’t seen one in a long time.
It’s very unlikely any system running bash will require the space, and the lack of the space seems to be the most common usage now.
But for the utmost historical compatibility, use the space.
We have chosen to use #!/usr/bin/env bash in the longer scripts and functions we’ve made available to download (see the end of the Preface for details), because that will run unchanged on most systems.
However, since env uses the $PATH to find bash, this is arguably a security issue , albeit a minor one in our opinion.