followup question to https://unix.stackexchange.com/questions/364/allow-setuid-on-shell-scripts . there is a very good answer by Gilles. alas, I do not understand it. nothing described there seems intrinsically different between executables and interpretables.
scripts had a race file-replacement condition, but Unix locking is not necessary to fix this. any C executable is first read and then executed. this could be done as easily with the interpretable code as with executable code. most (shell) scripts are not longer than most C executables, either, so both can be loaded first. the fact that earlier implementations first read one line, then closed the file, then reopened it (and thus suffered this race condition), is not intrinsic. it just happened to be ancient implementation. is this not easily universally fixable in all unix implementations by reading the whole interpretable script file?
the run-time necessary to accomplish a specific function is vulnerable, but this applies to both C code and the interpreter. do, say, shell or python scripts add/have vulnerable runtimes?
any (C) executable can call other shell programs the same way that an interpreted language can. programs passing to one another was originally claimed to be the Unix way, so we should do this often.
all of this is more or less stated in Gilles' answer, perhaps except the explicit "read all first, execute second". instead, it describes /dev/fd/ equivalent implementations.
so I am still missing it. what is intrinsically different? (the only security feature I can think of is that by banning suid scripts, we have made it more difficult for noobs to write any setuid scripts.)
was there a committee that made and explained their decision for, say, ubuntu, where I can read the motivation?