Re: ENOEXEC from exec*() functions...?

[Paul Smith]

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.