On 10/31/21 12:06 PM, Roger Morris wrote:
> Thanks for the reply. Though POSIX may allow this, still the last
> line of the following example is rather unexpected behavior
>
> $
> $ echo echo MY LOCAL tmp/date SCRIPT > tmp/date
> $ chmod +x tmp/date
> $
> $ PATH=.:/bin
> $ date
> Sun 31 Oct 2021 11:59:07 AM EDT
> $ hash -l
> builtin hash -p /bin/date date
> $ cd tmp ; date ; cd ..
> MY LOCAL tmp/date SCRIPT
This seems weird and non-intuitive (why not use the hashed value?), but
it's actually a special case that's handled explicitly in the code. If the
PATH search that results in a value being put into the hash table finds `.'
in the PATH before finding the full path, the hash table remembers that
fact and -- as a special case -- checks whether `./name' is an executable
file before returning the hashed value on subsequent lookups. It's strange,
but everyone seems to do it.
> $
> $ PATH=.:/bin
> $ command -p date
> Sun 31 Oct 2021 11:59:50 AM EDT
> $ hash -l
> builtin hash -p /bin/date date
> $ cd tmp ; date ; cd ..
> Sun 31 Oct 2021 12:00:03 PM EDT
Once you know the above, this makes sense: `command -p' uses a magic value
for PATH, and since that value doesn't include `.' the search doesn't find
`.'. This means the full path gets put into the hash table without the flag
that says `look at ./date first', and the hashed value gets used.
The behavior would, of course, differ if `command -p' didn't do anything
with the hash table.
Chet
--
``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/
