> Use command -v instead Huh? That's a shell builtin, not an executable. That's next to useless. > which is widespread but not standardized What can possibly

> Use command -v instead Huh? That's a shell builtin, not an executable. That's next to useless. > which is widespread but not standardized What can possibly need standardization about "prints the full path to a command"??? > which in its barest form fails to handle builtins and aliases Yes, because it's an executable, not a builtin. This means that it is usable from outside of a shell, which is quite a significant benefit. Additionally, there is no path to a builtin or alias - so it actually handles both how it says on the tin: it returns no path. Moreover, it's rarely useful to check for a builtin or alias from a non-interactive context. > Just compare the arguments of the most common ones I have literally never once had to pass a single argument to which, except the name of a command. At which point it has literally always given me back the path to that command (or nothing). But, let's compare, shall we? - All 4 implementations support `which which`, with identical semantics - All 4 implementations support `which -a which`, with identical semantics - 2 implementations support no other options - 1 implementation has a -s flag for silent operation, which can be portably replaced by redirecting output. - 1 implementation has many more options... which appear to mostly be useful interactively. I'm not sure why this implementation is presented as "GNU"; the linked page clearly attributes it to a "Carlo Wood" > For scripts, command -v is better, because it’s simpler and machine-readable. I strongly doubt that `command -v` actually does what the author wants it to do. I can't imagine why you would want to end up with the string "alias ls='ls --color=auto'" in your variable when you were looking for "/bin/ls", as `which` would return.