Mike Frysinger wrote:
type -P reflects what the shell will attempt, not what is useful. the fact that it's not usable is irrelevant.
---- The fact that it is not usable is relevant. The type command says it will return the name of the file that will be executed if name was used as a command name, this is true. However, I would say that returning non-executable objects for use as a command is not very useful if you are looking for a command. If the file cannot be executed (and, especially, isn't readable), bash returns an answer it *knows* is wrong for use as a command.
if you want to see if it's executable, use `[ -x ... ]`. -mike
----- Bash checks if they are executable -- when /bin/echo was executable, my PATH has /usr/bin before /bin and bash skipped /usr/bin/echo because it wasn't accessible and returned /bin/echo because it was executable. Only when /bin/echo was made unexecutable did bash return a non-executable file for use as a command -- instead of returning nothing (""). It's also the case, that I can test if 'echo' is there or not, till I'm blue in the face, but that doesn't indicate whether or not the command will work, in this case, as it is a builtin. Maybe I'm in the minority, but I think the type command is *fundamentally*, used to look up commands -- things that are executable. Returning something that isn't because it fits some Faustian rules seems a bit perverse, no?