0001789: if command name contains slash, it cannot be arg0 for execl()

Notes
(0006579) larryv (reporter) 2023-11-22 06:20	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.

(0006580) Don Cragun (manager) 2023-11-22 07:18	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.

(0006581) Guy Harris (reporter) 2023-11-22 09:42	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".

(0006582) Guy Harris (reporter) 2023-11-22 09:57	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.

(0006596) geoffclare (manager) 2023-12-11 14:58	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’’.

(0006621) nick (manager) 2024-01-15 17:28 edited on: 2024-01-22 16:14	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) ... the first argument be a filename string associated with the process being started. 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’’. to: ... the first argument be simply a string associated with the filename of the process being started. 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. In some cases the filename in the string 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’’.

(0006626) gbrandenrobinson (reporter) 2024-01-17 17:43	"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.

(0006627) nick (manager) 2024-01-18 16:08	Note: 0006621 has been updated to break the run-on sentence as suggested.

(0006631) larryv (reporter) 2024-01-19 19:31	Re: Note: 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.

(0006633) nick (manager) 2024-01-22 16:15 edited on: 2024-01-22 16:16	Note: 0006621 has been updated as suggested by Note: 0006631

Issue History
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	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 Note: 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:09	nick	Note Added: 0006628
2024-01-18 16:10	nick	Note Deleted: 0006628
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

Aardvark Mark IV