> The which program has been deprecated, and writes a warning to standard error (but still works, so long as stderr is not being captured along with stdout). Shell script writers are advised to use command -v instead. Interactive bash shell users are advised to use type, or type -a. In zsh which is already a shell builtin, so interactive zsh users are not affected.
> 'command -v' also returns 0 for shell built-ins, whereas 'which' only searches $PATH.
In what cases is one using anything to check for a built-in shell command? I've written quite a lot of bash, and this has never come up.
I've learned to prefer 'command -v' because it's always available, whereas on minimal or busybox installs sometimes 'which' is not included.
The annoying part seems to be more that the ergonomics of a single straightforwardly-named command (e.g. 'which') are friendlier and easier to remember compared to an unintuitively-named command requiring the addition of a flag.
Why can't we move in a more ergonomic direction by promoting 'which' to a BASH built-in?
This reminds me of the suggestion not to use access(2) and X_OK to decide to call execve(2) -- because the kernel behavior of executing the binary may work differently and fail for some other reason, or perhaps even there's a race condition where the executable bit gets removed between your calls.
This is typical advice given to people writing shells.
On this basis I would say using either which or command -v in unsound; neither of them are a guarantee that execve(2) will succeed. But like many things done in shell scripts, it's a "good enough" kind of solution that will do the right thing a majority of the time.
https://gstreamer.freedesktop.org/releases/1.22/ https://news.ycombinator.com/item?id=34505574
If so, this is huge!
… Please try out upgrading your bullseye systems to bookworm now and report issue you encounter”
Roger that!
