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.ll...@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.ri...@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.ri...@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
>

Reply via email to