Re: type -aP: intentional behaviour or a bug?

[Adam Vodopjan]

On 16/12/2022 21:44, Chet Ramey wrote:
> On 12/15/22 7:18 PM, Adam Vodopjan wrote:
>> Hey guys!
>>
>> I need to expand a command to all its locations under $PATH. For example,
>> on my system /bin is a symlink to /usr/bin so for 'ls' there should be
>> both /usr/bin/ls and /bin/ls listed.
> 
> OK.
> 
>>
>> For the purpose I wanted to use either 'type -ap' or 'type -aP'. I know
>> there is a difference in 'type -p' vs 'type -P':
> 
> `type -aP' is the more appropriate choice, since it forces the $PATH search.
> 
> 
>> But I was sure '-ap' should be the same as '-aP'. Somehow I've found out
>> this:
> 
> Yes, `type -aP' looks in the hash table. That's really the only difference.
> It's been that way since I added it in 2001. I forget why, but it was
> probably something like why force the $PATH search when it's not going to
> be used when you use the name as a command. That's a long time ago, though.
> 

Bash man page: 'If a command is hashed, -p and -P print the hashed value',
but it says later: 'The table of hashed commands is not consulted when
using -a'.

It looks like a 20 yo bug, or a problem with docs. '-a' states for
'everything', not for 'everything, if only it is not hashed yet in case of
-P. But with -p it is everything indeed'.

> If you want to force the $PATH search, remove the name from the hash
> table before doing it (hash -d ls).
> 
>>    /* If the user isn't doing "-a", then we might care about
>>       whether the file is present in our hash table. */
>>    if (all == 0 || (dflags & CDESC_FORCE_PATH))
> 
>> So with CDESC_FORCE_PATH bit set (-P flag) it completely ignores -a flag.
> 
> No, only if it's present in the hash table.
> 

My bad