On Mon, 2018-07-30 at 17:29 +0300, Eli Zaretskii wrote: > > Which doesn't sound like something that would be helped by re- > > running > > as a shell script. Maybe this is a feature of GNU/Linux and other > > systems use ENOEXEC when there's no #! line? > > But in GNU Make, SHELL can be set to anything, including a command > that runs some executables which the Unix kernel and the Unix shell > don't recognize. Maybe that code tries to cater to this situation? > AFAIU, such a situation will not be resolved by execvp's fallback to > the shell, because I presume execvp will call the standard shell, > right?
Well, this code won't help with that. It will run "/bin/sh foo bar" and the execvp() call will succeed and the process will be replaced by the shell. If "foo" is not a shell script then the shell will still try to run it and fail with some sort of syntax error or something. That will be a very different error than execvp() returning ENOEXEC. The only way you'd get ENOEXEC here is if, I suppose, execvp() couldn't find a shell at all. Even then you probably just get ENOENT (I didn't hide /bin/sh on my system to test this :)) which is what you'd get for any other non-existent program. As far as I can tell the only way execvp() can return ENOEXEC is if you try to run a 64bit binary on a 32bit system, or a Windows binary on a GNU/Linux system, or something like that: something where the kernel can't even load the program. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
