I find it interesting that Debian even cares whether 'which' is POSIX or not, given that they don't ship a lot of POSIX commands (e.g. 'ed' and 'bc') by default. It seems to me much of the value in such a standard is you can either rely on it or not; deliberately omitting some of the specified utilities, then using other utilities as arguments in a systems architeecture discussion seems like a self-contradiction. Unfortunately the Debian wiki entry on POSIX merely defines it and doesn't enlighten us as to policy decisions.
Debian's Which Hunt
21–30 of 257 posts
Re: Debian's Which Hunt
#22> The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job".
While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely upon which existing and printing out the path of an executable without a deprecation warning. I would expect a Debian maintainer to realize that. Debian does patch the heck out of upstream packages, but they don't provide everything, and all Debian users are not going to want to go to equal effort to patch all of the build files for packages Debian doesn't provide.
Re: Debian's Which Hunt
#23'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
shellcheck throws a lint error if it finds you using which and tells you to use 'command -v' instead.
Re: Debian's Which Hunt
#24Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.
Absolutely. Transparent governance is really hard, and it was quite nice to see an example of a conflict handled and resolved so well, right out in the open.
Not like systemd, then.
[Edit] I didn't mean the systemd thing lacked transparency; I just mean the result wasn't "nice".
Re: Debian's Which Hunt
#25'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
shellcheck throws a lint error if it finds you using which and tells you to use 'command -v' instead.
Thank you for reminding me about this neat tool, it saved my ass a couple of times.
Re: Debian's Which Hunt
#26Wow, talk about a tempest in a tea kettle. Bikeshedding like this is why Linux will never achieve any significant market share for average consumers. (Because all that mental effort could have been spent on solving some real problem instead of philosophical conformity.)
This is not bikeshedding, at least as I see it. Debian is used in millions of systems and many may rely on the exact output of 'which' command. Their job is to make these systems incredibly reliable, make improvements and make sure those improvements are rolled out as smoothly as possible. This is unsexy like plumbing and maintenance is unsexy, but still absolutely instrumental to society. Linux overall has an amazin…
> Their job is to make these systems incredibly reliable
They why did they switch to systemd? It seems like linux developers have nothing better to do than just rename stuff with no obvious advantage to the new standards but breaking backwards compatibility with the old standards.
Re: Debian's Which Hunt
#27'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
I learned about `command -v` just now reading this article. I only knew of `which` and `type` (as well as the very convenient `=executable` syntax that expands to the path of the binary, but I think that's a zsh-ism). What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.
It's pretty much useless for the same purpose:
$ which ls
/usr/bin/ls
$ type ls
ls is aliased to `ls --color=auto'
$ command -v ls
alias ls='ls --color=auto'
Re: Debian's Which Hunt
#28'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
I learned about `command -v` just now reading this article. I only knew of `which` and `type` (as well as the very convenient `=executable` syntax that expands to the path of the binary, but I think that's a zsh-ism). What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.
> I learned about `command -v` just now reading this article
Me too and I'm sure we're not the only ones. But look at this quote from the article:
> surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job
This is an mind-bogglingly misguided attitude. Anyone that has never heard of an obscure POSIX command is incompetent? Or is it that really that most people don't want to spend their time writing awful shell scripts and figuring out exactly what is POSIX and what isn't?
Re: Debian's Which Hunt
#29'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
I noticed that on Ubuntu at least, `command -v` has the same output format of `which`, where `command -V` does not. Did you accidentally use the latter one?
[deleted]
Re: Debian's Which Hunt
#30'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
What's not machine-friendly about `command -v`'s output? Can you not just use the exit status? Or did you mean that you avoid `which` in favor of `command -v`?
See my post above.