POSIX doesn't specify how exactly the shebang is to be interpreted. Quoting from the [`exec` family of functions' RAITONALE][1]: > One common historical implementation is that the *execl()*, *execv()*, > *execle()*, and *execve()* functions return an [ENOEXEC] error for any file not recognizable as executable, including a shell script. When > the *execlp()* and *execvp()* functions encounter such a file, they > assume the file to be a shell script and invoke a known command > interpreter to interpret such files. This is now required by > POSIX.1-2008. These implementations of *execvp()* and *execlp()* only > give the [ENOEXEC] error in the rare case of a problem with the > command interpreter's executable file. Because of these > implementations, the [ENOEXEC] error is not mentioned for *execlp()* > or *execvp()*, although implementations can still give it. > > Another way that some historical implementations handle shell scripts > is by recognizing the first two bytes of the file as the character > string "#!" and using the remainder of the first line of the file as > the name of the command interpreter to execute. > > One potential source of confusion noted by the standard developers is > over how the contents of a process image file affect the behavior of > the exec family of functions. The following is a description of the > actions taken: > > 1. If the process image file is a valid executable (in a format that is executable and valid and having appropriate privileges) for this > system, then the system executes the file. > > 2. If the process image file has appropriate privileges and is in a format that is executable but not valid for this system (such as a > recognized binary for another architecture), then this is an error and > *errno* is set to [EINVAL] (see later RATIONALE on [EINVAL]). > > 3. If the process image file has appropriate privileges but is not otherwise recognized: > > 1. If this is a call to *execlp()* or *execvp()*, then they invoke a command interpreter assuming that the process image file is a shell > script. > > 2. If this is not a call to *execlp()* or *execvp()*, then an error occurs and *errno* is set to [ENOEXEC]. And earlier on, in the DESCRIPTION, it says the `execlp` and `execvp` shall assume the: > In the cases where the other members of the exec family of functions > would fail and set *errno* to [ENOEXEC], the *execlp()* and *execvp()* > functions shall execute a command interpreter and the environment of > the executed command shall be as if the process invoked the [*sh*][2] > utility using *execl()* as follows: > > execl(<shell path>, arg0, file, arg1, ..., (char *)0); > > where <*shell path*> is an unspecified pathname for the [*sh*][2] > utility, file is the process image file, and for *execvp()*, where > *arg0*, *arg1*, and so on correspond to the values passed to *execvp()* in *argv[0]*, *argv[2]*, and so on. So, these functions run the equivalent of `sh file ...`. And when the script is run from a POSIX shell, the effects of the shebang are unspecified. See [2.1, Shell Introduction][3]: > 1. The shell reads its input from a file (see [*sh*][2]), from the **-c** option or from the [*system()*][4] and [*popen()*][5] functions defined in the System Interfaces volume of POSIX.1-2008. If the first > line of a file of shell commands starts with the characters "`#!`", > the results are unspecified. Zsh doesn't mind, bash does: $ cat foo.sh #! env perl echo $0 $ zsh -c ./foo.sh Can't locate object method "echo" via package "./foo.sh" (perhaps you forgot to load "./foo.sh"?) at ./foo.sh line 2. $ bash -c ./foo.sh bash: ./foo.sh: env: bad interpreter: No such file or directory Don't rely on not specifying `PATH` lookups in the shebang. (I know I ran `zsh -c ./foo.sh` instead of `zsh foo.sh`, however, the intention here was to show what the shells do in executing commands can differ.) [1]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html#tag_16_111_08 [2]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sh.html [3]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01 [4]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/system.html [5]: http://pubs.opengroup.org/onlinepubs/9699919799/functions/popen.html