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 c...@case.edu http://tiswww.cwru.edu/~chet/
