91–97 of 97 posts
Earlier quoted context omitted.
On Mac, with an alias I don't get the same answer from the two anyway: $ command -v emacs alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw "$@"' $ which emacs /opt/local/bin/emacs
That happens on every system I believe. It does for my RHEL boxes anyway. That also isn't the behavior I am looking for so I will stick with "which".
Earlier quoted context omitted.
On Mac, with an alias I don't get the same answer from the two anyway: $ command -v emacs alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw "$@"' $ which emacs /opt/local/bin/emacs
Correct, because they do two different things. `which` is a standalone executable which searches the environment's PATH for the named command. It doesn't know about commands which aren't executables (i.e. builtins and aliases). `command` is a shell builtin which tells you exactly what that shell in its current state would run.
Earlier quoted context omitted.
Isn't reporting the builtin the best behavior, since that's what will run if you type `command`?
No. There is no ‘best behavior’. If your aim is to discover which piece of software provides an executable you know you're running, whether it's wrapped by an alias or not, you want the behavior of `which`, and the behavior of `command -v` won't help you. If your aim is to discover what will run when you type a command in your shell, the behavior of `command -v` (or `type`) is what you want, and the `which` program w…
Other times I want to use `command`: most often to bypass an alias, but with `-v` mode it's handy to get the definition of an alias.
I suppose `find "$PATH" -name NAME` is roughly equivalent to `which NAME`.
Earlier quoted context omitted.
No. There is no ‘best behavior’. If your aim is to discover which piece of software provides an executable you know you're running, whether it's wrapped by an alias or not, you want the behavior of `which`, and the behavior of `command -v` won't help you. If your aim is to discover what will run when you type a command in your shell, the behavior of `command -v` (or `type`) is what you want, and the `which` program w…
Exactly. I've been troubleshooting updating some libraries on an embedded system recently, and running a lot of `/lib/ld-linux.so --list "$(which )"` on various things to figure out what `-rpath`s I need to pass to the linker. I want the command to fail if I give it a builtin or alias! Other times I want to use `command`: most often to bypass an alias, but with `-v` mode it's handy to get the definition of an alias.…
> I suppose `find "$PATH" -name NAME` is roughly equivalent to `which NAME`.
Only if you're on Fish! Remember that ‘normal’ shells use `:` as the PATH separator :)
> 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…
You can freely choose that the problems don't apply to you, and you can be angry at POSIX and/or Debian for whatever happened or not as many others in this comment section. But I don't understand why you chose to write a belligerent comment as if any of it is the author's (yes me, but I didn't submit it to HN) fault or as if he is arguing in front of a committee to take it away from you.
As for Carlo Wood: https://savannah.gnu.org/projects/which links to http://www.gnu.org/software/which/ that in turn links to https://carlowood.github.io/which/. Maybe do your research if you want to be a pedant?
i thought this was going to be a little quiz of which things are and are not POSIX