5 ms·

$ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'

• Taywee 5y ago
  In this case, `which` is just searching the `PATH` and not telling you what will actually run. `command` is correctly informing you of the whole story. I'll add that `which` on my setup is using the zsh built-in, which also informs of aliases and built-ins. So yes, that's more useful if you're using `which` to determine "Does this name exist as an executable anywhere in the PATH", but most people use it to mean "What will actually be executed if I run this word as a command?" edit: Or, most often in scripts, it's used just for its exit status to tell whether the command exists to be executed at all.
  • marcosdumay 5y ago
    > `command` is correctly informing you of the whole story. You are assuming a bit too much here. Which tells you the preferred executable with that name, while command tells you what will run if you execute it on the current shell. From what I can tell, one does not replace the other. But yes, for your example of usage, command is more correct.
• deleted 5y ago
  [deleted]
• anderskaseorg 5y ago
  In a script, there will almost never be any aliases defined, because noninteractive shells don’t load ~/.bashrc. $ sh -c "which ls; command -v ls" /bin/ls /bin/ls If the script is #!bash rather than #!sh, it’s not even possible to define an alias. $ bash -c "alias ls='ls --color=auto'; which ls; command -v ls" /bin/ls /bin/ls
  • pxc 5y ago
    You can still define functions in scripts, and those might wrap commands or accidentally share their names.