> The point is that I don't really want to add a new exec type.  You can
> consider things that require an interpreter like this to be "scripts".
> The trick is determining which script interpreter to give the script to.

> If you can have multiple different non-#! script types handled, you
> can't really use a sysctl() for it.  (Well, not in the traditional
> sense... sysctl turns knobs, it doesn't add things to lists, etc.)

As I recall, #! was first handled by the C shell, rather than the kernel
(4.1-ish timeframe?), and was then added to the kernel due to the difficulty
of maintaining parallel but only vaguely similar code in two different
command interpreters.  Now that there are, what, 7 or 8 popular command
interpreters, that's clearly out, but perhaps unknown file formats could
be handed to a registered scripting program instead of being immediately
failed.  (Arranging for that program's exit code to be turned back into
an errno of ENOEXEC would require some trickery, though.)

However, other than speed issues (and how speed-critical is an error case,
anyway*) it's not clear that the kernel needs to know about all the possible
interpreted-file magic types.  (There are security issues involved, though,
since implicit read permission has to be given to execute-only files to allow
the interpreter to work; thus the interpreter itself has to be a system
program, and the user must be completely unable to interpose a different
program in its place.)



* OK, it's not always an error case; it's legal to "execute" scripts for
"the current interpreter" without giving them a magic number (i.e. shell
scripts without #! /bin/sh), but you're depending on those scripts being
run from the correct shell, which is no longer a good bet at all.