I can appreciate this. I've seen similar things come up in the OpenBSD community. A lot of thought is given, but often times a decision is made fairly judiciously by the benevolent dictator, Theo.
Debian's Which Hunt
111–120 of 257 posts
Re: Debian's Which Hunt
#112I've used Debian since (I think) from late 00s and Linux from 98. Didn't even know what Which does. Maybe I forgot ;)
Re: Debian's Which Hunt
#113I'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.
FreeBSD with ZFS and being the backend of network CDN's wants a word or two with you.
Re: Debian's Which Hunt
#114By this logic, we'd also rename awk to something more "meaninful" because the names of Aho, Kernighan, and Weinberger are just historical artifacts. They are indeed, but we're talking about a real-world "we all talk UNIX" language here that's been around for a long time -- perilously close to 2.14 billion seconds in fact. Lots of people and programs speak, read, and write this UNIX language. It's creeping up on natural human language status. This "which' is a vocabulary word of that language.
Heavily used languages evolve. And you know what? They never evolve healthily when they ban the use of "obsolete" vocabulary. Languages embody history. Even PowerShell!
This language won't benefit from an Académie Française - style iron-fisted rule.
Re: Debian's Which Hunt
#115My memory might be tricking me but I learnt about 'which' on a late '80s HP9000 running HP-UX, using bourne shell and it's output was the same as GNU which. But I might be swapping memories with early Linux.
Re: Debian's Which Hunt
#116> 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…
Wait. Is the problem here extra _text_ in the output that shouldn't be parsed? 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.
> I cannot believe people are parsing text output from other commands in the year 2021
If you're writing shell scripts, there aren't any other options.
Here's a lovely little snippet to find the current wifi network for a reMarkable 2. If it's "Aardvark", it runs rsync. :)
iw wlan0 info | grep -Po '(?Parsing text from a command is a headache, but it works most of the time. There often isn't an API or syscall to get the data you need on a specific system.
My favorite ugly hack is having a Ruby on Rails application write a file to disk so it can be processed by another program using a shell and then picking up the output file after that program finishes.
This requires a lot of cleanup and diligence to keep from leaking files... or you can set up a nightly cronjob using find to locate all of the files created more than a week ago and delete them. :)
Linux and Unix are a pile of hacks. It isn't going to change anytime soon.
Re: Debian's Which Hunt
#117Earlier quoted context omitted.
In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.
Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.
They did do that. It's "command -v".
Re: Debian's Which Hunt
#118Here'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…
"command -v" isn't reliable because several shells (including Dash) don't obey the POSIX standard. See https://github.com/oilshell/oil/blob/8fbc09bb3254cee944b0450...
Then that's too bad for anyone who tries to use non-standard shells. It's one thing to violate a vague, rarely used standard. It's quite another to violate what is most likely the most broadly supported standard on *nix systems.
Re: Debian's Which Hunt
#119When 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.
Re: Debian's Which Hunt
#120Earlier 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?
I think aliases are only used in interactive shells:
$ sh -c 'command -v ls'
/bin/ls