On Sat, 1 Nov 1997 01:04:25 -0600 (CST) 
 Ty Sarna <tsarna@endicor.com> wrote:

 > I like the idea of an LKM for this. There's no reason it needs to be
 > there at boot time, and it should be doable as a LKM without too much
 > difficulty. Along similar lines, I always thought it'd be neat to have
 > similar functionality for DOS executables with doscmd -- just run
 > command.com or myprog.exe or whatever right at the shell. Even call DOS
 > apps from scripts, etc. I think one of the DOS-under-Unixes for SCO or
 > Xenix did this, but I never saw it myself.

Actually, I think it would be perfectly appropriate as an in-kernel
thing... requiring that it be an LKM is broken.  Ignoring the fact that
not all ports support LKMs yet, on general principle, anything that
can be LKM'd should also be able to be statically included in the kernel,
if it's shipped with the system.

 > Maybe what's needed is a generic run-this-program-on-files-with-
 > this-magic-number facility.

Yes, it seems like this is a natural extension of EXEC_SCRIPT.  I could
see possibly changing the EXEC_SCRIPT code to do the following:

	if (has #! magic)
		run program with interpreter listed after #!
	else
		for each magic/interpreter pair
			if magic matches
				run program with this interpreter

	return ENOEXEC

The real meat of what you want to do is already in the kernel.

Then system calls:

	int addinterp(const char *magic, size_t magiclen,
	    const char *interp, size_t interplen);

	returns 0 on success, EEXIST if magic number already has an
	interpreter, and other appropriate error codes for errors
	on copyin, if interpreter doesn't exist, and if data structures
	can't be allocated.

	int reminterp(const char *magic, size_t magiclen);

	returns 0 on success, ESRCH if magic number doesn't exist.

...and then some way to query which interpreters are already registered.
This could probably be done easily enough with a kmem groveler.

Now the evil part :-)

You could probably rip a bunch of the magic interpretation stuff out of
file(1), making a libmagic, or something, and write a program (call it
interp(1) :-) that could add and remove interpreters.. perhaps something
like:

	interp foo.java /path/to/java/interpreter

...finds the magic, and adds the interpreter with the addinterp(2) system
call.  Similarly, you could remove the interpreter with:

	interp -d foo.java

Ok, so take this with a grain of salt (seeing as how I am still recovering
from last night's Halloween party, and only on my second cup of coffee :-),
but I think this idea might be worth pursuing.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-6                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939