[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ENOEXEC from exec*() functions...?
From: |
Paul Smith |
Subject: |
Re: ENOEXEC from exec*() functions...? |
Date: |
Mon, 30 Jul 2018 10:56:41 -0400 |
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.