I've always used whereis instead of which anyway. More useful info out of one command.
Which is not Posix
11–20 of 97 posts
Re: Which is not Posix
#12Seems like `which` should be added to POSIX
Re: Which is not Posix
#13Yeah, no thanks, I'm going to keep using `which`, and distributions are going to support it, no matter how "standard" `command -v` is. The only reason we're talking about this is that it's so noteworthy that any distro would seriously suggest people avoid `which`, which is the de facto standard.
Busybox also supports both variants, which is nice. C:\Users\luser>busybox64 sh ~ $ command -v ssh C:/WINDOWS/System32/OpenSSH/ssh.exe ~ $ which ssh C:/WINDOWS/System32/OpenSSH/ssh.exe ~ $ exit
Busybox supports may subcommands, and on systems based on it virtually every common command is aliased to it, but nice isn't included.
which which
/bin/which
which nice
Edit: I just pulled the the latest dockerhub image, and nice is one of the included applets. So if you really want which to be nice, upgrade busybox.
Re: Which is not Posix
#14I do not understand this Debian 'which' kerfuffle, but seems a big argument over nothing. But for me, 'type' is my go to in scripts. And as a tcsh user, I never knew 'which' was a thing in Bourne shells until I checked a few minutes ago. I do not know when it appeared, but I thought in the 'old days' 'which' was specific just to [t]csh. Also, I never heard of 'command -v' until I saw it in LWN a few days ago :)
which is not a thing in bourne shells; it's a separate executable. If it were a builtin then there wouldn't be a kerfuffle; there are multiple implementations of "which" and Debian doesn't want to privilege one of them, but if Debian base scripts use one, then it must privilege one of them.
Re: Which is not Posix
#15I remember being bitten my `which` on Solaris not giving return codes. I was not yet aware of `hash` or `command`
At $PREVIOUS_JOB, I tried to maintain dotfiles that could be used on Solaris and RHEL interchangably, and I had a bunch of conditionals for enabling various completions.
Re: Which is not Posix
#16Discussed at length previously here:
Re: Which is not Posix
#17I do not understand this Debian 'which' kerfuffle, but seems a big argument over nothing. But for me, 'type' is my go to in scripts. And as a tcsh user, I never knew 'which' was a thing in Bourne shells until I checked a few minutes ago. I do not know when it appeared, but I thought in the 'old days' 'which' was specific just to [t]csh. Also, I never heard of 'command -v' until I saw it in LWN a few days ago :)
which is not a thing in bourne shells; it's a separate executable. If it were a builtin then there wouldn't be a kerfuffle; there are multiple implementations of "which" and Debian doesn't want to privilege one of them, but if Debian base scripts use one, then it must privilege one of them.
In this case, the simplest solution is to probably privilege one of them and then everybody get back to work.
Re: Which is not Posix
#18OK, I don't get `command`. When I run `command time -v sleep 10` it clearly runs /usr/bin/time on my system (the bash builtin doesn't have the -v option), but if I run `command -v time` it outputs `time`, corresponding to the builtin. How is this helpful? Also shouldn't `command` and `command -v` find the same things? edit: Well apparently this is the standard behavior [1]. So lookup is not the same for `command ` vs…
If only there was a functioning standards body that could add a new option to command that reported this sort of info.
Re: Which is not Posix
#19let's collectively mark POSIX as deprecated and move on
Re: Which is not Posix
#20I do not understand this Debian 'which' kerfuffle, but seems a big argument over nothing. But for me, 'type' is my go to in scripts. And as a tcsh user, I never knew 'which' was a thing in Bourne shells until I checked a few minutes ago. I do not know when it appeared, but I thought in the 'old days' 'which' was specific just to [t]csh. Also, I never heard of 'command -v' until I saw it in LWN a few days ago :)
which is not a thing in bourne shells; it's a separate executable. If it were a builtin then there wouldn't be a kerfuffle; there are multiple implementations of "which" and Debian doesn't want to privilege one of them, but if Debian base scripts use one, then it must privilege one of them.
It is a built-in in zsh. Thanks to that, it will recognize when something is a built-in, an alias, a function or a command and report accurately what will be executed when you type it in without the "which".