You've undoubtedly seen shell scripts begin with "#!/bin/bash" and you may have noticed Perl scripts that begin with "#!/usr/bin/perl". You may have also
noticed that you seemingly don't really need "#!/bin/bash" but "#!/usr/bin/perl" isn't quite so optional.
Let's take a look at a simple and pointless shell script. We'll run it with and without "#!/bin/bash" and see what happens.
Notice that the "sleep"'s are still running - that too is a story for another day, but they'll go away soon enough. So, right away we see one advantage of the shebang: it lets us see the name of a shell script in "ps".
1050 ttys001 0:00.01 /bin/bash ./t.sh
1085 ttys001 0:00.01 sh ./tcopy.sh
So that's another thing: if our shebang-less script is run by something other than bash, it's /bin/sh that ends up running it. Certainly in this case it doesn't matter - sh or bash will do the same thing. But other scripts might have bash specific commands and /bin/sh would fail or behave badly.
$ time ./t.sh;time ./tcopy.sh
Whoah! What's that?? Why is the shebangless version faster?
The man page for bash tells us the difference in the "COMMAND EXECUTION" section:
If the search is successful, or if the command name contains one or more slashes, the shell executes
the named program in a separate execution environment. Argument 0 is set to the name given, and the
remaining arguments to the command are set to the arguments given, if any.
If this execution fails because the file is not in executable format, and the file is not a direc-
tory, it is assumed to be a shell script, a file containing shell commands. A subshell is spawned
to execute it. This subshell reinitializes itself, so that the effect is as if a new shell had been
invoked to handle the script, with the exception that the locations of commands remembered by the
parent (see hash below under SHELL BUILTIN COMMANDS) are retained by the child.
If the program is a file beginning with #!, the remainder of the first line specifies an interpreter
for the program. The shell executes the specified interpreter on operating systems that do not han-
dle this executable format themselves. The arguments to the interpreter consist of a single
optional argument following the interpreter name on the first line of the program, followed by the
name of the program, followed by the command arguments, if any.
So, it's quicker to fail and run the subshell than to succeed. Not by much, of course, but the difference is real. I can't imagine a circumstance where it would actually matter unless you had some strange system that was constantly firing of short little shell scripts to do this and that - you'd need to be doing an awful lot of that to even notice~