Re: bug? "type -P xxx" returns "xxx" that isn't executable...(or readable)

[Greg Wooledge]

On Thu, Jul 31, 2014 at 11:40:18PM -0700, Linda Walsh wrote:
> Ishtar:/> ll {,/usr}/bin/echo
> -rw-r--r-- 2 136753 Nov 19  2013 /bin/echo
> --w------- 2 136753 Nov 19  2013 /usr/bin/echo
> >sudo chmod +x /bin/echo          
> Ishtar:/> type -P echo
> /bin/echo                                     #correct

How is that correct?  Neither of them is executable.  If you believe
that type -P should respect file permissions, neither of these should
be reported.

On Fri, Aug 01, 2014 at 06:07:38AM -0400, Mike Frysinger wrote:
> read what Chet said.  type -P reflects what the shell will attempt, not what 
> is useful.  the fact that it's not usable is irrelevant.
> 
> if you want to see if it's executable, use `[ -x ... ]`.

That does indeed seem to be the case.

golem:~$ touch ~/bin/kumquat
golem:~$ type kumquat
kumquat is /home/greg/bin/kumquat
golem:~$ command -v kumquat
/home/greg/bin/kumquat

How bizarre.  But, as you say, this is apparently how Bash behaves.
I was hoping that "command -v", being an actual POSIX command, would work,
but it seems not.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
says:

  8.3 Other Environment Variables
  ...
  PATH
    ...
    The list shall be searched from beginning to end, applying the
    filename to each prefix, until an executable file with the specified
    name and appropriate execution permissions is found.

Bash behaves as expected in POSIX compatibility mode:

golem:~$ bash --posix -c 'command -v kumquat'
golem:~$ bash -c 'command -v kumquat'
/home/greg/bin/kumquat

In non-POSIX-compatibility mode, I guess you just have to iterate
through PATH yourself, or iterate through the results of "type -a".
(Or toggle POSIX compatibility on just for this check.)