Debian's Which Hunt (opens in new tab)

It's also worth reading through the POSIX manpages for POSIX sh if you want to be a good shell scripter.

The output and return result differ significantly between BSD, GNU and OSX, so you can't just run $(which python) and get a straightforward response back.

Granted, I didn't know about `command -v` so I'm not sure if it works better in practice.

Ugh. Now that the UNIX universe has collapsed unto Linux, BSD's and very, very few other *X's, it is less of an issue, but «which», due to it having never been enshrined in standards, has never been safe to use in shell scripts, and an invocation could yield a suprise for the unprepared. At least on Solaris (if I am not mistaken), the «which» output yields *two* lines, of which the first is useless (along the lines of «ohiyo, lookie at what I have found») and with the second being the actual path to the binary. So «which» has never been truly portable and safe to use.

Virtually every command can fail in some way, and they will all write to stderr (or worse, stdout, but that's not what happened here). How is that unexpected at all? How else would you communicate the change? (For the sake of argument, let's say the change is going to happen regardless, since you're arguing for the irresponsibleness of showing a warning.)

But which which do you make standard?

When one says it's non-standard, it normally means that you don't know if the way you are using it will work on other places.

You can't quite be. Standards are norms, so there's no escaping normativity there. And simply describing existing conventions can't solve the problems that standards are introduced to solve, which is when you are faced with multiple, sometimes incompatible ways of doing things.

There's room for a kind of descriptivist reconciliation with updates to standards, though. You can say ‘Future versions of the standard should, as far as possible, directly incorporate contemporaneous usage. Where contemporaneous usage is divergent, they should reflect the virtues of contemporaneous usage in a new standard capable of replacing divergent uses.’

Slowly, methodically, and with minimal user impact.

As mentioned at the end of the article, what first appears a waste of time for a small issue could also be seen as a beautiful illustration of the democratic process that makes Debian so stable/widely adopted.

That is how things get done. If you do the work you get to decide.

In the 0.001% that an issue get taken up by the technical committee as being important for the whole project, then after usually a long time they make a decision that in special cases may overrule the maintainer. That happens about once or twice a year? I am unsure how often a decision actually goes against the maintainer, and there is only a few cases a year (https://www.debian.org/devel/tech-ctte).

This naturally doesn't stop anyone from being too active on the mailing lists and arguing over small things, but I would think people are wasting less time there than they do arguing lesser important topics on social media.

Many years ago, I posted that stable was too old. All the Debian users were quick to tell me to run testing, that it wasn't a bad experience in spite of the name. Well, after converting all my machines to Debian, a package that was critical to my work was broken and I was not at all impressed with the handling of the situation, so I moved on. I can definitely see something like the story in the article playing out.

'everyone' = existing users. New users are generally harmed by redundancy and mess.

They could just have kept which has it has been for more than a decade and nothing would have happened. That's the decision that prevailed in the end but the fact that it had to go all the way to the Technical Committee before sanity prevailed says a lot about the utter madness of the Debian development process.

My own preference these days is to explicitly use /bin/zsh and just rely on zsh behaviour (e.g. "$+commands[ls]"). It's not "compatible" in the sense of "POSIX compatible", but it's more compatible in the sense of "much higher chance everything will work on a random system", with the only downside that people will need to install zsh. I think that's a fair trade-off for many (though obviously not all) cases.

macOS has an executable called `command`? Does any other OS?

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.

If you're specifying your shebang as #!/bin/sh then you should not assume you have access to functions like type or binaries like which, but you can generally assume you have access to the command built-in.

What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.

  if command -v foo >/dev/null; then
    foo ...
  else
    bar
  fi

For interactive use, just go ahead and use which if that's what you like. Most people will be using bash or z-shell or whatever, and portability isn't a concern.

Interactive shell usage and shell scripting are quite distinct. Yes, there's a huge overlap, but as in any other language, when you're writing a properly structured program (not a one-off or hack), you're expected (for good reasons) to follow more consistent rules and conventions.

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.

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.

Probably not. The programs should (and likely actually do) parse only stdout. The warning is on stderr.

I find the whole thing pointless, I disagree with Adams that only incompetent people would depend on which, and I expect actually removing /usr/bin/which to be problematic, but I don't expect the warning itself to break much of anything, except maybe blood pressure cuffs...

I cannot believe people are parsing text output from other commands in the year 2021. To me that this sounds like incredibly unsafe practice and am just astounded it happens.

Everyone has different preferences though, e.g. for me vim is an essential package. That's why I have a few functions in my bashrc that installs packages in different environments. Here are some of them, with a representative excerpt of the packages:

- function defaultinstall { apt install curl sudo vim ping etc. }

- function defaultinstall_laptop { apt install lshw powertop gnome-power-manager etc. }

- function defaultinstall_wifi { apt install wavemon iw etc.

- function defaultinstall_android { apt install sqlite3 etc. }

- function defaultinstall_optional with various languages like php and ruby, a mariadb client, cloc, gifsicle, iperf3, apt-file and it then runs apt-file update, etc.

Before having these functions, I noticed that I'd often be missing packages (sometimes while offline). If you really want `which`, you can install the variant you want. I would do the same (because, interactively, I find `which` easier to type, even if I use the portable `command -v` in scripts).

Linux overall has an amazing separation of concerns structure (inherited from the POSIX tradition). The user-facing details you might be worried about like the interface design etc. are all handled by separate teams that expect their base to be reliable and stable so they can make other changes.

In my opinion, this is a good thing. Aiming for increasing "market share for average consumers" usually implies focusing on the standard baseline of functionality. There is nothing wrong with this, but this invariably cuts off tinkerers and enthusiasts who care about playing with SDRs and LIDARs and other fringe capabilities as much as (and usually more than) they care about the simplicity of the WiFi setup.

For simplest possible internet browsing there is ever-simpler Windows, with its design choices such as sharing of WiFi access and creeping ads. Just my 2c.

Since Debian does this all out in the open, we just get to watch how the sausage is made.

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 and energy on backwards compatibility.

> 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.

No tempest, no bikeshedding. That seems like the polar opposite of whatever you are criticizing.

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.