3 ms·
Point being, it doesn't help you finding /usr/bin/command via regular search in PATH and it reports the builtin instead.
by steerablesafe 5y ago
Point being, it doesn't help you finding /usr/bin/command via regular search in PATH and it reports the builtin instead.
- joemi 5y agoIsn't reporting the builtin the best behavior, since that's what will run if you type `command`?
- pxc 5y agoNo. 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 won't help you.
- SAI_Peregrinus 5y agoExactly. I've been troubleshooting updating some libraries on an embedded system recently, and running a lot of `/lib/ld-linux.so --list "$(which <executable>)"` 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`.
- pxc 5y agoIs calling `ld-linux.so` as an executable like that the same thing as calling `ldd`? is there any reason to prefer to invoke it that way? > 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 :)