View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001984 | 1003.1(2024)/Issue8 | Shell and Utilities | public | 2026-06-13 03:14 | 2026-07-29 07:19 |
| Reporter | hvd | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Interpretation Required | Resolution | Accepted As Marked | ||
| Name | hvd | ||||
| Organization | |||||
| User Reference | |||||
| Section | command utility | ||||
| Page Number | 2728 | ||||
| Line Number | 90105 | ||||
| Interp Status | Proposed | ||||
| Final Accepted Text | see 0001984:0007442 | ||||
| Summary | 0001984: Ambiguous requirements for command -v on printing absolute pathnames | ||||
| Description | The requirements for command -v read: - Executable utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-provided functions that are found using the PATH variable (as described in 2.9.1.4 Command Search and Execution), shall be written as absolute pathnames. This is ambiguous as to whether "that are found using the PATH variable" applies to "Executable utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-provided functions", or only to "any implementation-provided functions". Given that "command_names including a <slash> character" are never looked up using the PATH variable (as pointed out by Herbert Xu on the dash mailing list), the intent must be that "that are found using the PATH variable" applies only to "any implementation-provided functions", but at least one shell (bash) does not currently write command_names including a <slash> character as absolute pathnames, even in POSIX mode, and in my opinion, the current text of the standard does not say it should. | ||||
| Desired Action | Change - Executable utilities, regular built-in utilities, command_names including a <slash> character, and any implementation-provided functions that are found using the PATH variable (as described in 2.9.1.4 Command Search and Execution), shall be written as absolute pathnames. to - Executable utilities, regular built-in utilities, and command_names including a <slash> character, shall be written as absolute pathnames. - Any implementation-provided functions that are found using the PATH variable (as described in 2.9.1.4 Command Search and Execution) shall be written as absolute pathnames. | ||||
| Tags | No tags attached. | ||||
|
|
Interpretation response ------------------------ The standard is unclear on this issue, and no conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor. Rationale: ------------- As described, the sentence is ambiguous, and different shells have chosen different implementation strategies. Notes to the Editor (not part of this interpretation): ------------------------------------------------------- On page 2728, lines 90105-90111, Change
to
|
|
|
Interpretation proposed: 13 July 2026 |
|
|
My sense is that “command_names including a <slash> character […] that are found using the PATH variable” is inverted. Command names that do NOT include a <slash> character are found using the PATH variable, and it then makes sense for the subordinate clause to apply to all the options in the list, not just the last one. I agree that it is important to say «It is unspecified whether command_names including a <slash> character shall be written as absolute pathnames or as relative pathnames.» This bring the specification into line with the historical and current behaviour of several common shells, including Ash (Busybox & Dash), Bash, and Zsh. $ command -v ../bin/foo ../bin/foo Furthermore, these shells output a prefix from PATH verbatim: $ PATH=../bin command -v foo ../bin/foo I believe it would be detrimental to force a change onto these and other shells, as relative paths are less likely to be broken than absolute ones, as can be seen using Ksh: $ ksh $ pwd ksh: pwd: cannot determine present working directory [Permission denied] $ ls -dog ../.. foo d--------- 3 4096 2026-07-28 22:04:32.606740605 +1200 ../.. -rwxrwxr-x 1 0 2026-07-28 21:41:31.39708201 +1200 foo $ command -v ./foo /home/REDACTED/tmp/a/b/c/foo $ ls -dog "$( command -v ./foo )" ls: cannot access '/home/REDACTED/tmp/a/b/c/foo': Permission denied $ mv ~/tmp/a ~/tmp/aa $ ls -dog "$( command -v ./foo )" ls: cannot access '/home/REDACTED/tmp/a/b/c/foo': No such file or directory $ For the cases where an absolute path is actually wanted, we now have the `realpath` utility, so there is little benefit (and demonstrable detriment) in mandating absolute path normalisation on the output of other utilities. I suggest that the wording be changed:
|
|
|
> Furthermore, these shells output a prefix from $PATH verbatim: I cannot speak for busybox and zsh, but dash looks happy to take a change but is waiting for this bug to be resolved to see what actually needs to be implemented (whether it needs to handle only relative paths in $PATH, or also relative paths in command names): the maintainer wrote "I'll wait for the standard (or bash) to be fixed before taking this change" on the mailing list in response to a patch for this. As for bash, it behaves differently in POSIX mode and in non-POSIX mode. You have tested non-POSIX mode. In POSIX mode, bash does convert relative paths in $PATH to absolute. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-06-13 03:14 | hvd | New Issue | |
| 2026-06-18 16:21 | nick | Note Added: 0007442 | |
| 2026-06-18 16:22 | nick | Status | New => Interpretation Required |
| 2026-06-18 16:22 | nick | Resolution | Open => Accepted As Marked |
| 2026-06-18 16:22 | nick | Page Number | - => 2728 |
| 2026-06-18 16:22 | nick | Line Number | - => 90105 |
| 2026-06-18 16:22 | nick | Interp Status | => Pending |
| 2026-06-18 16:22 | nick | Final Accepted Text | => see 0001984:0007442 |
| 2026-07-13 09:01 | agadmin | Interp Status | Pending => Proposed |
| 2026-07-13 09:01 | agadmin | Note Added: 0007449 | |
| 2026-07-28 10:35 | m.kealey | Note Added: 0007464 | |
| 2026-07-28 10:36 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:37 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:40 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:41 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:43 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:44 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:44 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:45 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:47 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:48 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:48 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:49 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:49 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:54 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 10:55 | hvd | Note Added: 0007465 | |
| 2026-07-28 11:05 | m.kealey | Note Edited: 0007464 | |
| 2026-07-28 11:05 | m.kealey | Note Edited: 0007464 |
