PING: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

[Martin Buchholz]

https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

"""Historically, there have been two ways that implementations can exec
shell scripts.

One common historical implementation is that the execl(), execv(),
execle(), and execve() functions return an [ENOEXEC] error for any file not
recognizable as executable, including a shell script. When the execlp() and
execvp() functions encounter such a file, they assume the file to be a
shell script and invoke a known command interpreter to interpret such
files. This is now required by POSIX.1-2017. These implementations of
execvp() and execlp() only give the [ENOEXEC] error in the rare case of a
problem with the command interpreter's executable file. Because of these
implementations, the [ENOEXEC] error is not mentioned for execlp() or
execvp(), although implementations can still give it.

Another way that some historical implementations handle shell scripts is by
recognizing the first two bytes of the file as the character string "#!"
and using the remainder of the first line of the file as the name of the
command interpreter to execute.
"""

On Tue, Jun 4, 2019 at 11:54 PM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi David,
>
> You are right. I am pretty sure there are ancient historical reasons for
> doing this by hand instead of letting exec() deal with scripts itself.
> Martin or Roger may know more.
>
> But I think right now this is more of a compatibility concern - changing
> this behavior has the risk of breaking lots of user code. Since we have not
> the manpower to deal with this - look at how long simple fixes are in
> review, we are all busy elsewhere - chances of changing this are small.
>
> Cheers, Thomas
>
>
> On Tue, Jun 4, 2019 at 10:14 PM David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> In this case, going from what the execve(2) Linux man page says (and Mac
>> seems to agree), if the script were executable it would have a '#!'
>> interpreter string and the kernel would execute it anyway, would it not?
>> What case would be solved by explicitly starting a shell?
>>
>> On Tue, Jun 4, 2019 at 2:15 PM Roger Riggs <Roger.Riggs at oracle.com>
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> If the argument is not an .exe, then it may be a command shell script
>>> (.sh, etc.)
>>> Only the system knows it is not an exe (errno == ENOEXEC), so it then
>>> passes it as
>>> the first argument to /bin/sh that will handle the shell files.
>>>
>>> And yes, count me as a Reviewer and reviewed.
>>>
>>> Roger
>>>
>>> On 06/04/2019 12:14 PM, Thomas Stüfe wrote:
>>>
>>> On Tue, Jun 4, 2019 at 5:09 PM Roger Riggs <Roger.Riggs at oracle.com>
>>> wrote:
>>>
>>> ...
>>>
>>>
>>> Then I ran an strace over it and saw this:
>>>
>>> 5332 [pid  3911] execve("./sleep2", ["./sleep2"], [/* 78 vars */]
>>> <unfinished ...>
>>>                                                       ..
>>> 5342 [pid  3911] <... execve resumed> )      = -1 ENOEXEC (Exec format
>>> error)
>>> 5343 [pid  3911] execve("/bin/sh", ["/bin/sh", "./sleep2"], [/* 78 vars
>>> */] <unfinished ...>
>>> 5347 [pid  3911] <... execve resumed> )      = 0
>>>
>>> So, if the first exec fails for whatever reason, we try again, passing
>>> the executable file name as argument to the system shell. This does not
>>> feel right? Do you know why we do this?
>>>
>>>
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>> Thank you Roger. Can I consider the patch to be reviewed by you?
>>>
>>> ..Thomas
>>>
>>>
>>>
>>
>> --
>> - DML
>>
>