POSIX doesn't specify how exactly the shebang is to be interpreted. Quoting from the
exec family of functions' RATIONALE:
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
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.
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]).
If the process image file has appropriate privileges but is not otherwise recognized:
If this is a call to execlp() or execvp(), then they invoke a command interpreter assuming that the process image file is a shell
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
execvp shall run scripts with
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
utility using execl() as follows:
execl(<shell path>, arg0, file, arg1, ..., (char *)0);
where <shell path> is an unspecified pathname for the sh
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, argv2, 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:
- The shell reads its input from a file (see sh), from the -c option or from the system() and popen() 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
$ 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.)