Re: hash not restored after running command -p

[Chet Ramey]

On 11/1/21 4:42 AM, Robert Elz wrote:
> I agree, this looks to be broken in bash - "command -p cmd" is (logically)
> 
>       oldpath=$PATH
>       PATH=/standard:/system:/path
>       cmd
>       PATH=$oldpath
> 
> and should act (as if) that way.

Clearly that's not the case. None of the side effects from assigning to
PATH occur.

What the OP wants here is for `command -p' not to

1. use the hash table

2. modify the hash table

There's nothing in the POSIX description of `command' or `hash' that
implies this. Both end up referencing

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01

which says, in part,

"Once a utility has been searched for and found (either as a result of this
specific search or as part of an unspecified shell start-up activity), an
implementation may remember its location and need not search for the
utility again unless the PATH variable has been the subject of an
assignment."

which seems at best inconclusive. I can see not using the hash table
(otherwise why use `command -p' at all?), but I don't see any support
for 2.

> 
> which is how it should be - the hash table is intended to speed PATH
> searches for commonly used commands, nothing should be found there
> which wouldn't be found from a PATH search - 

This isn't true in bash, either: `hash -p' exists.


> This is also somewhat inconsistent in bash, if one does, with the
> same setup as above, but without having done the "command -p ls",
> then:
>       PATH=/bin ls
> 
> the ls command works, "ls" is found by the PATH search, but is not added
> to the hash table (which is correct).   A subsequent "ls" correctly
> says:
>       bash: ls: command not found
> 
> If it is to be considered correct to add the entry in the command -p
> case, why would it not be correct in this case as well? 

Bash actually used to implement `command -p' that way
(`command -p name stuff' was implemented as the equivalent of
`PATH=magicpath name stuff'), but it's not what you want: if you do it like
that, `name' ends up inheriting the magic value of PATH and I got bug
reports about that.

So `command -p' has to be magic: it uses a magic internal version of $PATH
for lookups, which may come from a call to getconf(3) but doesn't have to,
but otherwise behaves exactly as if PATH were set to that value for the
purpose of POSIX's command search and execution.

You can argue for a change in behavior, which I suppose is what's happening
here, but there's little support for it in the standard.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/