I don't really understand what the need is to kill off `which` command. Is it a maintenance burden?
Debian's Which Hunt
211–220 of 257 posts
Re: Debian's Which Hunt
#212Earlier quoted context omitted.
Minimally breaking solution 1) Require the output of which in non-interactive environments to conform to the behavior a reasonable shell script author is likely to have assumed the specification was based on observations. In the case of historic 'which' that would be to print the absolute path to an executable without any other arguments, or a specific error message and exit status. 2) Allow __interactive__ shells to…
I feel like I'm going to be bit when I try commands interactively and then that act differently in a script. I think the current solution is the pragmatic one, don't standardize things you can't pull off standardizing! #!
The ls command does this: if output is to a tty then it prints in columns. Many commands add color when the output is a tty. I don’t think it would be a big issue.
Re: Debian's Which Hunt
#213I'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.
This was the case for literally all of the unix toolset before Posix came along, and how they solved this exact problem in every other case was to define a common subset (which usually involves almost all the functionality you really actually use most of the time) and make that the standard and everyone implements anything that's missing from the standard into their version and keeps all their existing extensions. That's why on linux you can do 'ps -leAf' or 'ps auxww' and have them do almost exactly the same thing for example.
Re: Debian's Which Hunt
#214I don't really understand what the need is to kill off `which` command. Is it a maintenance burden?
People pick the weirdest hills to die on, and in open source we can see it happen in real time. If this happened inside a big corp, we’d never see one stubborn maintainer getting overruled by their peers / bosses.
Re: Debian's Which Hunt
#215I'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.
I don't see that there's a POSIX way to provide the same functionality of 'which' without searching $PATH yourself.
The article mentions “command -v”.
Re: Debian's Which Hunt
#216Earlier quoted context omitted.
I don't understand why people even care about POSIX in 2021. It's not like Linux distributions are POSIX certified. So many things can't be good because it's not in POSIX or because POSIX requires something else. People actually force themselves to write scripts in some mythical POSIX shell that nobody uses.
There are some cases where it makes sense. For example let's say I was developing something like a build script for ncurses: that runs on many different systems, and sticking to POSIX for compatibility makes sense there. There still quite a bit of stuff like that. But a lot of the time I see people write some shell script that's Linux or BSD specific in the first place as "compatible" shell scripts. I don't see how t…
> The only advantage I can see is that dash is a bit faster than bash or zsh, but it's not that much of a difference in real scripts.
It also consumes quite a bit less memory, which can be relevant for shell wrappers or other long running scripts. That's the primary reason I started writing my scripts for dash rather than bash. The other advantages (portability, lack of cognitive overload caused by bash's infinitely long list of features and quirks) were an unforeseen bonus.
Re: Debian's Which Hunt
#217> * 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,…
I rarely write/read shell scripts, and have been using "command -v" for years.
Re: Debian's Which Hunt
#218I'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.
Unix predates POSIX -> All Unix flavors were non standard + your reasoning -> POSIX cannot exist.
Re: Debian's Which Hunt
#219Here'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?
[deleted]
Re: Debian's Which Hunt
#220I remember writing scripts with $(which something) in the past. I cannot remember why I needed that.