View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001789 | Issue 8 drafts | Shell and Utilities | public | 2023-11-22 02:24 | 2024-01-22 16:15 |
| Reporter | Mark_Galeck | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Error |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Product Version | Draft 3 | ||||
| Name | Mark Galeck | ||||
| Organization | |||||
| User Reference | |||||
| Section | Volume 2, Chapter 3 | ||||
| Page Number | 865, 2487 | ||||
| Line Number | 80936, 29495 | ||||
| Final Accepted Text | see 0001789:0006621 | ||||
| Summary | 0001789: if command name contains slash, it cannot be arg0 for execl() | ||||
| Description | Line 80936 says, if command name contains a slash, to execute as if with execl() with arg0 argument set to the command name. But that is impossible because line 29495 says arg0 points to a filename, and line 1646 says that filename shall not contain slashes. | ||||
| Desired Action | not sure, probably change line 29495 to say that arg0 points to a path | ||||
| Tags | tc1-2024 | ||||
| related to | 0001645 | Closed | 1003.1(2016/18)/Issue7+TC2 | execvp( ) requirements on arg0 are too strict |
|
|
It is not true that "line 29495 says arg0 points to a filename". What it says is that "[the] argument arg0 should point to a filename string" (emphasis mine). That is a recommendation; as far as I can tell, the standard does not actually impose a semantic requirement on arg0. |
|
|
The pages and line numbers listed in this bug report refer to Issue 8 draft 3 of the standard; not to 1003.1(2016/18)/Issue7+TC2. I will update the category of this bug report to match the referenced draft. |
|
|
Perhaps the paragraph containing line 29495 should :-) note that, to use IETF RFC 2119 terminology: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) code calling exec() SHOULD make arg0 point to point to a filename string that is associated with the process being started by one of the exec functions, but that programs MUST NOT assume that argv[0], as passed to main(), will be such a string, without an agreement between the program calling execl() and the program being executed by execl() to that effect. For what it's worth, at least on macOS Ventura, bash, ksh, dash, and zsh all provide an argv[0] that is equal to the string used to invoke the program, i.e., with a program "arg0", in /tmp, which prints out the value of argv[0]: ./arg0, when run in /tmp, prints "./arg0"; arg0, when run with a PATH that includes "." prints "arg0"; /tmp/arg0 prints "/tmp/arg0". |
|
|
And if "the program calling execl()" is a POSIX-compliant shell, then section 2.9.1.6 Non-built-in Utility Execution of the current Draft 3 specifies that: If the command name does not contain any <slash> characters, the command name shall | 80907 be searched for using the PATH environment variable as described in XBD Chapter 8 (on | 80908 page 167): If the search is successful, the shell shall execute the utility with actions equivalent | to calling the execl() function as defined in the System Interfaces volume of POSIX.1-202x with the path argument set to the pathname resulting from the search, arg0 set to the command name, and the remaining execl() arguments set to | the command arguments (if any) and the null terminator. ... If the command name contains at least one <slash>: If the named utility exists, the shell shall execute the utility with actions equivalent | to calling the execl() function defined in the System Interfaces volume of POSIX.1-202x with the path and arg0 arguments set to the command name, and the | remaining execl() arguments set to the command arguments (if any) and the null terminator. so the filename string passed as arg0 to the exec function used by the shell is *not* a filename, it's a pathname; if you want a filename, you'll have to strip off everything up to the last path separator. |
|
|
Note that there is existing rationale about the recommendation to pass a filename. See P872 L29785-29791:Although some existing applications pass a pathname rather than a filename string in some circumstances, a filename string is more generally useful, since the common usage of argv[0] is in printing diagnostics. In some cases the filename passed is not the actual filename of the file; for example, many implementations of the login utility use a convention of prefixing a <hyphen-minus> ('-') to the actual filename, which indicates to the command interpreter being invoked that it is a ``login shell’’. |
|
|
On page 865 line 29495, and 29499 change: (D4 p877 line 29519 and 29523)... should point to a filename string that is associated with the process being started by one of the exec functions. to: ... should point to a string that is associated with the filename of the process being started by one of the exec functions. and add to Application Usage, page 872 after line 29773: (D4 p874 line 29796) The string in arg0 or argv[0] is typically the basename of the path of the file being executed, but this standard does not require it to be so. The program executed will see this string in the first element of the argv[] array passed to its main() function, and may alter its functionality based on this. On page 872 Rationale, line 29785, change (D4 p874 line 29808)
to:
|
|
|
"Most applications pass a filename string or a pathname string, a filename string is more generally useful, since the common usage of argv[0] is in printing diagnostics." This is a run-on sentence. I would resolve it by changing the first comma to a period and updating subsequent *roff spacing (if necessary) and capitalization afterwards. Other solutions are possible, of course. |
|
|
0001789:0006621 has been updated to break the run-on sentence as suggested. |
|
|
Re: 0001789:0006621:The string in arg0 or argv[0] is typically the basename of the path of the file being executed. However, there is no requirement in this standard that this is so, and the program executed will see this string in the first element of the argv[] array passed to its main() function, and may alter its functionality based on this.Minor copyediting nit, but the first clause of the second sentence seems more closely related to the first sentence than to the rest of the second sentence. Suggestion: The string in arg0 or argv[0] is typically the basename of the path of the file being executed, but this standard does not require it to be so. The program executed will see this string in the first element of the argv[] array passed to its main() function and may alter its functionality based on it. |
|
|
0001789:0006621 has been updated as suggested by 0001789:0006631 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-11-22 02:24 | Mark_Galeck | New Issue | |
| 2023-11-22 02:24 | Mark_Galeck | Name | => Mark Galeck |
| 2023-11-22 02:24 | Mark_Galeck | Section | => Volume 2, Chapter 3 |
| 2023-11-22 02:24 | Mark_Galeck | Page Number | => 865, 2487 |
| 2023-11-22 02:24 | Mark_Galeck | Line Number | => 80936, 29495 |
| 2023-11-22 06:20 | larryv | Note Added: 0006579 | |
| 2023-11-22 07:18 | Don Cragun | Note Added: 0006580 | |
| 2023-11-22 07:19 | Don Cragun | Project | 1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts |
| 2023-11-22 07:21 | Don Cragun | Product Version | => Draft 3 |
| 2023-11-22 09:42 | Guy Harris | Note Added: 0006581 | |
| 2023-11-22 09:57 | Guy Harris | Note Added: 0006582 | |
| 2023-12-11 14:58 | geoffclare | Note Added: 0006596 | |
| 2024-01-15 16:40 | nick | Relationship added | related to 0001645 |
| 2024-01-15 17:28 | nick | Note Added: 0006621 | |
| 2024-01-15 17:29 | nick | Final Accepted Text | => see 0001789:0006621 |
| 2024-01-15 17:29 | nick | Status | New => Resolved |
| 2024-01-15 17:29 | nick | Resolution | Open => Accepted As Marked |
| 2024-01-15 17:30 | nick | Tag Attached: tc1-2024 | |
| 2024-01-15 17:31 | nick | Note Edited: 0006621 | |
| 2024-01-17 17:43 | gbrandenrobinson | Note Added: 0006626 | |
| 2024-01-18 16:08 | nick | Note Edited: 0006621 | |
| 2024-01-18 16:08 | nick | Note Added: 0006627 | |
| 2024-01-18 16:44 | eblake | Note Edited: 0006621 | |
| 2024-01-19 19:31 | larryv | Note Added: 0006631 | |
| 2024-01-22 16:14 | nick | Note Edited: 0006621 | |
| 2024-01-22 16:15 | nick | Note Added: 0006633 | |
| 2024-01-22 16:16 | nick | Note Edited: 0006633 |
