Live data from Hacker News

Debian's Which Hunt

lwn.net

181–190 of 257 posts

Re: Debian's Which Hunt

#181
Without commenting on what Debian should do about this, I've pretty much given up using `which` myself.

Since `which` is an external command (it's built into some shells, but not bash), it doesn't know about aliases, shell functions, or builtin shell commands.

I've found that bash's built-in `type` command (with its various options) does whatever `which` does, and often does it better.

I also use `command -v foo >/dev/null` to detect whether the command `foo` exists -- for example:

    if command -v less >/dev/null ; then
        export PAGER=less
    fi
I suppose I could also use `type` for the same purpose.

It would be nice if `type` and/or `command` had an option to check whether a command exists without printing anything, but having to add `>/dev/null` is only a minor annoyance.

Re: Debian's Which Hunt

#182

When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.

> The amazing thing is 'which' was working perfectly fine for everyone. 'everyone' = existing users. New users are generally harmed by redundancy and mess.

Except new users are coming from other platforms that have a "which", and also new new users have to learn the commands and it helps if they have intuitive terminology like "which" instead of opaque names like "command -v" which at a glance I'd assume fetches version info of the given command.

Re: Debian's Which Hunt

#183

Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.

The POSIX shell builtin command -v basically already functions like which, and the whole purpose of which is to tell you where in $PATH a command is

It doesn't function exactly like "which" because it's missing two key features: an intuitive name, and a million man-hours of experience being used.

Re: Debian's Which Hunt

#184

Earlier quoted context omitted.

And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?

They destabilize it less than other packaging ecosystems. I tried Manjaro the other day -- out of the box, wake from sleep was broken, bluetooth was broken, and 3/3 printers were broken. I eventually got sleep working with an older kernel version, I got bluetooth working with config file hacking, and I got the printers working with CUPS wrangling -- but on Ubuntu, all of this Just Worked for me. That's the point of i…

I don't see how deprecating "which" helps any of that, or any stability in general.

Re: Debian's Which Hunt

#185
post #108
post #45

I'm a descriptivist when it comes to standards. When everyone uses `which`, POSIX should add it. "but it's non-standard!" can be fixed by making it a standard.

Also, POSIX is basically irrelevant now. There are only two Unixen that anyone uses: RMS/Linux and whatever outdated garbage userspace Apple is shipping with macOS.

Moving away from standards won't make it any easier to diversify our operating system choices. Standards compliance is what allows alternatives to be usable with existing software.

A lack of alternatives simply means that not enough standardization is happening, and we need more standards compliance.

Re: Debian's Which Hunt

#186
post #84

Here's how zsh 5.8 behaves on macOS: $ which {which,type,command,vi} which: shell built-in command type: shell built-in command command: shell built-in command /usr/bin/vi $ type {which,type,command,vi} which is a shell builtin type is a shell builtin command is a shell builtin vi is /usr/bin/vi $ command -v {which,type,command,vi} which type command /usr/bin/vi Which is quite different from how bash 5.1 behaves: bas…

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

MS-DOS

Re: Debian's Which Hunt

#187
post #152

> * 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".* This feels a little tone-deaf to me. I've been using the *nix command-line and writing (and reading) shell scripts for 20+ years,…

You should be using ShellCheck or an equivalent linter on your shell scripts in POSIX mode if you want them to be portable; in POSIX mode it warns when using "which" instead of "command -v", and I think it also warns when using "whence" or "where" outside of zsh. There's a host of other Bashisms/GNUisms and other noncompliant antipatterns it checks for too.

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

Re: Debian's Which Hunt

#188

Earlier quoted context omitted.

> When I read stuff like this I can't help but wonder how anything ever even gets done on this project. 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 t…

I moved on from Debian some 9-10 years ago and I haven't regretted it once. Many sysadmin acquaintances and former colleagues of mine complained that upgrading Debian is often like rolling a dice (yes, even the stable and thus fairly old variant). An innocent "apt-get upgrade" moves configuration files and/or expectations where they are, or, what's even worse, changes the config files and silently moves the previous…

> For all the BS surrounding the "systemd vs. whatever-else-the-other-thing-was", I found the former made my life as a mid-tier Linux user and home-grown server admin much easier, too.

Yeah, I'm sympathetic to some of the anti-systemd stuff, but I've found writing systemd units so much easier and more reliable than upstart or sysv init scripts. And sd_notify is great.

Re: Debian's Which Hunt

#189
post #105

Earlier quoted context omitted.

>I can't help but wonder how anything ever even gets done on this project 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.

And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?

On Debian "unstable".

Re: Debian's Which Hunt

#190
post #105

When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.

>I can't help but wonder how anything ever even gets done on this project 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.

Slowly is right. Every time they release a package it's 2 years after the source code was published.
Post reply on HN