Re: [PATCH] exec: Print absolute paths for command location queries

Hi Harald,

On Sat, 6 Jun 2026, at 6:27 PM, Harald van Dijk wrote:
> On 06/06/2026 16:36, Kerin Millar wrote:
>> POSIX requires that, when reporting the location of a utility found by
>> searching PATH (or one named with a slash), the pathname written by
>> type, command -v and command -V be absolute:
>> 
>>      Executable utilities, regular built-in utilities, command_names
>>      including a <slash> character, and any implementation-provided
>>      functions that are found using the PATH variable [...] shall be
>>      written as absolute pathnames.
>> 
>> Presently, dash fails to conform in this regard. Address this issue by
>> incorporating a helper function that prefixes relative pathnames with
>> the shell's cached current working directory.
>
> Hi,
>
> Although this ensures that the written path is absolute whenever 
> possible, it does not ensure that the written path corresponds to the 
> command that would be executed. Although curdir cannot be altered by the 
> user, that does not mean it should be trusted for this purpose, because 
> the file system may have changed after the current directory was set.
>
> Consider:
>
>    cd /tmp
>    mkdir a
>    cd a
>    ln -s /bin/ls
>    PATH=. command -v ls # should print /tmp/a/ls or /tmp/a/./ls
>    mv /tmp/a /tmp/b
>    PATH=. command -v ls # must not print /tmp/a/ls or /tmp/a/./ls
>
> Printing /tmp/a/ls for that last line is worse than printing ./ls: ./ls 
> may not be absolute but at least resolves to the command that would be 
> executed.
>
> bash does not appear to consider this requirement useful, so in 
> non-POSIX mode just prints ./ls. In POSIX mode it prints /tmp/a/./ls twice.
>
> ksh prints /tmp/a/ls twice, regardless of POSIX mode.
>
> zsh prints ./ls twice, regardless of sh mode.
>
> yash correctly prints /tmp/a/./ls, followed by /tmp/b/./ls.
>
> My shell, gwsh, also prints /tmp/a/./ls, followed by /tmp/b/./ls.
>
> I think leaving it as printing a correct relative path is better than 
> printing a possibly wrong absolute path, personally. A change to print a 
> correct absolute path would have my support though, for whatever that is 
> worth.

It's a good point. How about using getcwd() and printing the relative path upon failure, even if to do so would not be strictly conforming?

-- 
Kerin Millar