Searching the Nix package repository can give you a good idea of how prevalent some software are used as a dependency because Nix packages requires all dependencies to be explicitly specified by design. Now, a quick search for "which" yields 2.5k hits [1]. Although a non-negligible portion of hits are just common uses of the word "which" in code comments, the other large portion of the hits are indeed dependencies on the "which" package. Although the use of the "which" command might potentially be fragile when considering cross-platform use, it seems like a really bad idea to deprecate it from a pragmatic point of view.
Debian's Which Hunt
31–40 of 257 posts
Re: Debian's Which Hunt
#32'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
What a mess. It sounds like command -v should have been the default from the get go and which should never have been introduced to debianutils. Once it was though, IMO, debian should never make a decision that breaks existing functionality.
In general, I don't care if you extend features beyond POSIX in your core utilities, but once you do, you have to assume people rely on that functionality.
I think this is the most poignant take:
>A proper transition plan would mean that I would never even notice this. One which would replace another and nothing would break. That is the sort of thing I expect to happen in Debian - we are generally good at this stuff, and it's a big reason for using the distro.
Re: Debian's Which Hunt
#33> 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 up…
As a political note: saying something like that is a great way to guarantee that if you want to remove `which`, you likely now have a set of engineers who will oppose your attempts to do so.
Those kinds of attitudes pushed me out of open-source engineering and into closed-source, commercial engineering, purely because it's nice to have a boss who can say "Don't talk to your peers like that; it's counterproductive" with some authority.
Re: Debian's Which Hunt
#34Wow, 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.)
One of the advantage to the more hierarchical approach found in many commercial software development houses is that someone has the authority to say "These are about the same, we're doing it this way, the decision is arbitrary, and anyone who doesn't toe the line can work on something else."
Makes it easier to avoid burning time on problems with equivalently-good solutions, or even not-equivalently-good-but-perfection-isn't-worth-the-cost-of-discovery.
Re: Debian's Which Hunt
#35'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`?
$ which true
/usr/bin/true
$ command -v true
true
$ which ls
/usr/bin/ls
$ command -v ls
alias ls='ls --color=auto'Re: Debian's Which Hunt
#36Wow, 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 a unit-shifter attitude. And I'm not trying to be rude, you need sales. But if you ignore long-term quality for short-term sizzle, you lose, at least if you're producing something like Debian. If you don't understand why something like this is important to get right, I'd suggest maybe finding out why other people do actually care about things like this. Or maybe reflect on why Microsoft spends so much money a…
Microsoft spends so much money and energy on backwards compatibility because it's good for developers; it lets them focus on solving problems, not tracking the frameworks they need to solve problems.
The Microsoft approach would be to support `which` forever. It's not a big enough quirk to justify removing it, and it's essential for some people's development process.
Re: Debian's Which Hunt
#37Wow, 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…
On speed of change: There is of course too slow (too stable) and too unstable. The job of a good maintainer is also to weight possible gains against the downstream effort. Each project has also its own promises -- if you project advertises stability, big changes will cause a lot of grief downstream. If your project advertises instability, users will be more ready for changes.
Re: Debian's Which Hunt
#38Earlier quoted context omitted.
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' Suddenly I find myself irritated at Debian despite not even using it. Why would they not just include the GNU one?
This is a very unlikely output when run from a script using the /bin/sh interpreter on Debian, though.
If that is the output you've gone out of your way to create an alias in a script, in which case it's reasonable output. It is what will happen when the script runs that command, after all.
Re: Debian's Which Hunt
#39I 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. Unf…
Debian's a bit funny. Maintainers tinker with packages more often than I'd like; they make changes to packages that already work perfectly well, and sometimes breakage occurs.
This is partly because of the autonomy that Debian package maintainers enjoy. I have slightly mixed feelings about that - but only slightly. I'd sooner have maintainer autonomy, and seriously-distributed decision making, than an overlord.
Re: Debian's Which Hunt
#40Wow, 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.)
It's ironic how a comment about 'bikeshedding' spawns five comments in the span of twenty minutes.
That second coffee is just kicking in.