> 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.