Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debian's Which Hunt

lwn.net

Post reply on HN
Print view View original

81–90 of 257 posts

Re: Debian's Which Hunt

#81

Post by scottlamb »

nonameiguess wrote: post #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 up…

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

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

Re: Debian's Which Hunt

#82

Post by WastingMyTime89 »

emptyparadise wrote: post #7

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

Still a gigantic waste of everyone time.

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.

Re: Debian's Which Hunt

#83

Post by pxc »

anderskaseorg wrote: post #69
goohle wrote: post #35

Earlier quoted context omitted.

$ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'

In a script, there will almost never be any aliases defined, because noninteractive shells don’t load ~/.bashrc. $ sh -c "which ls; command -v ls" /bin/ls /bin/ls If the script is #!bash rather than #!sh, it’s not even possible to define an alias. $ bash -c "alias ls='ls --color=auto'; which ls; command -v ls" /bin/ls /bin/ls

You can still define functions in scripts, and those might wrap commands or accidentally share their names.

Re: Debian's Which Hunt

#84

Post by pxc »

jagger27 wrote: post #66

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?

Re: Debian's Which Hunt

#85

Post by wahern »

dilawar wrote: post #2

'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.

If you're parsing the output of `command -v`, you're doing it wrong:

  if command -v foo >/dev/null; then
    foo ...
  else
    bar
  fi
From shell scripts it doesn't matter if foo is an alias because if it is an alias, it's one that the script created itself.

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.

Re: Debian's Which Hunt

#86

Post by jchw »

Taywee wrote: post #58
pornel wrote: 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.

The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the behavior, then many existing uses become non-standard, and the existing implementations have to decide to change to become standard and possibly break backward compatibility or remain the same and stay non-standard.

The behavior of which on different machines has a meaningful enough common subset that I would argue most people have absolutely no idea that there are this many different implementations. It’s possible this would lead to an undesirable standard that specifies less behavior than it should, but on the other hand, I believe that is easier to improve incrementally rather than all in one bandaid rip.

Re: Debian's Which Hunt

#87

Post by marcosdumay »

pornel wrote: 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.

> "but it's non-standard!" can be fixed by making it a standard.

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.

Re: Debian's Which Hunt

#88

Post by marcosdumay »

denton-scratch wrote: post #24
wutbrodo wrote: post #20

Earlier quoted context omitted.

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

The systemd thing was extremely transparent. It didn't reach a solution that satisfied everybody, but there wasn't any secrecy on it.

Re: Debian's Which Hunt

#89

Post by pxc »

anonydsfsfs wrote: post #64
pxc wrote: post #51

Huh. Apparently `command` is a shell builtin for POSIX shells, not a standalone program. You might still want `which` if you're running in a non-POSIX shell that doesn't implement `command`. Seems fine to deprecate its usage inside bash scripts or scripts that you know are pegged to an interpreter that implements `command`, though.

The Debian shell's implementation of "command" isn't POSIX compliant due to the following bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264

Also another comment on this post indicates that macOS does come with an executable in `/usr/bin/command`. I assume it does basically nothing.

Maybe it's there from when the default login shell was `tcsh`, since tcsh doesn't include a `command` builtin. In that case, it would provide the same functionality as long as no one defines a tcsh function or alias called `command`.

Re: Debian's Which Hunt

#90

Post by rwmj »

WastingMyTime89 wrote: post #82
emptyparadise wrote: post #7

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

Still a gigantic waste of everyone time. 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.

> Still a gigantic waste of everyone time.

It's a voluntary organization, I guess people enjoy this, and the decision was taken in the open. There are worse things in the world right now :-)

Post reply on HN