On Sat, Oct 30, 2021 at 01:53:55PM -0400, Chet Ramey wrote: > On 10/29/21 6:06 PM, Roger Morris wrote: > > > Bash Version: 5.0 > > Patch Level: 17 > > Release Status: release > > > > Description: > > I believe there's a bug in bash 4.4 (and still in 5.1) that wasn't > > there in 4.3.30 > > > > When 'command -p' runs, it no longer seems to restore the hash to its > > previous value. > > This came in in mid-2015 as part of a set of fixes to `command -p'. I think > the bash-4.4 and later behavior is correct: just because you're telling > command to use a standard path it doesn't mean it should not act like it > would in any other circumstance. There's nothing in POSIX that contradicts > that.
(Not using 'PATH=' as that would include the current directory). PATH=/dev/null command -p hostname hostname # executes /bin/hostname via the hash table I agree with OP that the behaviour is a bug, or at least unwanted behaviour. I could not find this in POSIX nor in the bash manual, but it seems true: Assignment to PATH clears the hash table. (Even when the value stays the same). Which could be an argument for clearing the hash table after 'commmand -p ...'. Though, preferably, the hash table is not modified in this case. A side note. The description, in the manual, on 'command' states: Run command with args suppressing the normal shell function lookup. Only builtin commands or commands found in the PATH are executed. ... I think the hash lookup should be mentioned, as the hash lookup is done before the builtin/PATH search, e.g.: PATH=/dev/null hash -p /bin/hostname foo command foo # executes /bin/hostname -- Regards, Mike Jonkmans This message was brought to you thanks to DST.