Jonathan Nieder <[email protected]> writes: > Russ Allbery wrote:
>> I think that's asking quite a lot of bash. Wouldn't it have to open >> the binary and parse the ELF headers, extracting the INTERP header, in >> order to verify that? Does it really make sense to encode >> understanding of ELF binary layout formats in bash? > I suppose it could check if the file exists itself, or it could always > use a message like "File or interpreter does not exist". I suppose, but I guess if I were the bash maintainer I would be unenthused by this slippery slope. Right now (presumably; I haven't looked at the code), it's calling the appropriate syscall via libc, getting back ENOENT, and printing out strerror(errno). Messing about with checking things afterwards is sort of second-guessing the kernel (what if the file was deleted between the point that it tried to run it and the point at which it tried to check for its existence?). If we want to distinguish between missing file and missing interpreter, wouldn't it be better to introduce a new errno value that correctly represents that difference? After all, the kernel knows which problem it had. It just collapses them into a single errno value. Of course, introducing a new errno value is hard and requires upstream coordination between the kernel and glibc, not to mention some possible impact on compatibility if any code out there is relying on getting ENOENT when the interpreter isn't found. Which, I suppose, is the argument for doing this in bash. (Although I'm inclined to agree with the original reassignment of the bug: this sort of magic seems like what command-not-found is for.) -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
