A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1645 
====================================================================== 
Reported By:                eblake
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1645
Category:                   System Interfaces
Type:                       Clarification Requested
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       Eric Blake 
Organization:               Red Hat 
User Reference:             ebb.execvp 
Section:                    XSH exec 
Page Number:                784 
Line Number:                26548 
Interp Status:              --- 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2023-03-22 19:47 UTC
Last Modified:              2023-03-23 08:11 UTC
====================================================================== 
Summary:                    execvp( ) requirements on arg0 are too strict
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0000953 Alias expansion is under-specified
====================================================================== 

---------------------------------------------------------------------- 
 (0006228) lacos (reporter) - 2023-03-23 08:11
 https://www.austingroupbugs.net/view.php?id=1645#c6228 
---------------------------------------------------------------------- 
It occurs to me that argv[0], as execvp() is currently required to fill it
in on the ENOEXEC fallback, could be irrelevant as far as $0 in the shell
script is concerned. To recap, the fallback is

  execl(<shell path>, arg0, file, arg1, ..., (char *)0);

Now if you compare that with the "sh" utility's specification, it seems to
correspond to the *sole* synopsis form where the "command_file" operand is
provided.

And then the spec states (in the description of the "command_file"
operand), "Special parameter 0 [...] shall be set to the value of
command_file". This means that argv[0] will never be visible to the script,
only to the shell executable.

(The next question is of course if the shell executable cares about
argv[0]. BusyBox does.)

This suggests that

- the normative section (description) should indeed be relaxed as Eric
says,

- the rationale need not recommend either "exec -a" or "sh -c", because $0
is already well specified. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2023-03-22 19:47 eblake         New Issue                                    
2023-03-22 19:47 eblake         Name                      => Eric Blake      
2023-03-22 19:47 eblake         Organization              => Red Hat         
2023-03-22 19:47 eblake         User Reference            => ebb.execvp      
2023-03-22 19:47 eblake         Section                   => XSH exec        
2023-03-22 19:47 eblake         Page Number               => 784             
2023-03-22 19:47 eblake         Line Number               => 26548           
2023-03-22 19:47 eblake         Interp Status             => ---             
2023-03-22 19:55 eblake         Description Updated                          
2023-03-22 20:05 eblake         Relationship added       related to 0000953  
2023-03-22 20:35 eblake         Note Added: 0006226                          
2023-03-22 21:19 eblake         Description Updated                          
2023-03-23 08:11 lacos          Note Added: 0006228                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to