file attributes

[John R. MacMillan]

|However, depending on what meaning (if any) you'd assign to "bloat",
|"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60
|lines to "kern_exec.c" in 4.3BSD, for example.

Like you, I'm not a fan of the term ``bloat''.  My reason for
mentioning #! was that I felt it belonged in user code, not because
it's big, but because there's no particularly good reason to put it in
the kernel.

|Presumably, your user-mode version would be done in the "execve()"
|library routine - i.e., instead of just being a wrapper around the
|"execve()" trap, as it is in most existing UNIX implementations, it'd
|check for ENOEXEC and, if that was the error, it'd check for a "#!"
|line, shuffle the argument list, and invoke the program specified by the
|"#!" line?

Actually, if I were about to change the semantics of a prominent UNIX
call, I would probably have given it a new name, but it's a little
late for that (not meaning to signal, I mean single, out the exec
calls :-) ).  Now that the use is widespread, I would do it the way you
suggest.  You could also get rid of the ugly hard-coded limits that
are in kern_exec.c; after all, dynamic sizing is easier in user code.

|(That'd lose the set-UID/set-GID capability, but it's not
|clear whether that's really a loss or not - even if you fix the known
|bugs with the set-UID shell script mechanism, would *you* trust some
|arbitrary shell, or the "awk"/"perl"/whatever interpreter, and the
|language it implements sufficiently that you'd want to write set-UID
|scripts in that language?)

I don't consider it a loss.  If you really REALLY need setuid scripts,
that too can be done without kernel support (ksh has an suid_exec
program to do this).  This has the added advantage that it gives the
sysadmin control over setuid scripts.

Just to be safe, I should say that I (obviously) do not claim to
represent my employer's views.