Live data from Hacker News

Which is not Posix

hynek.me

31–40 of 97 posts

Re: Which is not Posix

#31
post #26

Not sure why the outcome of "`which` is not POSIX" would be "essentially everybody should stop using `which` and start using `command -v`, which is poorly known, has different semantics, and is covered in relatively little introductory material" rather than "this is just another example of why POSIX has been nearly irrelevant for a long time now". systemd is not POSIX, either, but that's not taken as some justificati…

As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?). As for systemd, AFAIK system startup isn't covered by POSIX at all, so bsd init, sysv init and systemd are all equally not covered by POSIX. Which is fine, POSIX was never meant to cover every sing…

> As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?).

It's meaningless that there's no clear version that POSIX should standardize on – GNU `which` is the de facto standard on Linux. Debian is hardly going to ship FreeBSD's `which`, as even the discontinued Debian-on-FreeBSD kernel port shipped a GNU userland. (clarification: Debian ships its own `which`, which is not GNU `which` but is meaningfully close enough in behaviour that it's for the most part irrelevant and the fix, in any case, for being too nonstandard would be "ship GNU `which`", not "suddenly care about POSIX in this one case")

In practice, there is only one meaningful `which` on Debian, with clear semantics, and no possibility of confusion over behaviour.

Which is the reason for bringing up systemd. POSIX doesn't cover init, but it does cover many other system calls and behaviours that systemd explicitly rejects in favor of treating the behaviour of the specific Linuxisms it's built around as a de facto standard.

If Debian is fine with its init system being based on de facto standard, POSIX-incompatible Linuxisms, there is no logical reason for it to oppose treating the GNU userland as a similar de facto standard regardless of what the sclerotic POSIX standard says.

"Don't use `which` if your goal is to write a shell script portable beyond your specific Unix, because it has non standard behaviour" is fine advice, but "the Debian project must remove `which` because somebody might accidentally rely on its non-standardized behaviour in a script they also want to run on Illumos" is utterly daft given the hundreds if not thousands of other ways a Debian system goes beyond POSIX.

Re: Which is not Posix

#32

Not sure why the outcome of "`which` is not POSIX" would be "essentially everybody should stop using `which` and start using `command -v`, which is poorly known, has different semantics, and is covered in relatively little introductory material" rather than "this is just another example of why POSIX has been nearly irrelevant for a long time now". systemd is not POSIX, either, but that's not taken as some justificati…

> just pointless pedantry over something precisely because it is so low stakes.

You have defined Bikeshedding ;)

https://thedecisionlab.com/biases/bikeshedding/

Re: Which is not Posix

#33
post #21

Not sure why the outcome of "`which` is not POSIX" would be "essentially everybody should stop using `which` and start using `command -v`, which is poorly known, has different semantics, and is covered in relatively little introductory material" rather than "this is just another example of why POSIX has been nearly irrelevant for a long time now". systemd is not POSIX, either, but that's not taken as some justificati…

So… bike shedding?

Exactly what I thought when my scripts started spewing that annoying error. Even busybox has a 'which' implementation applet which (aha) is a debian based one.

Re: Which is not Posix

#34

I've always used whereis instead of which anyway. More useful info out of one command.

Say you want to edit a none binary executable (script file) that lives in PATH. Using the command: nano $(which scriptname) ..will open that script. This is one of the neat usecases of which.

Re: Which is not Posix

#35
post #26

Earlier quoted context omitted.

As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?). As for systemd, AFAIK system startup isn't covered by POSIX at all, so bsd init, sysv init and systemd are all equally not covered by POSIX. Which is fine, POSIX was never meant to cover every sing…

> As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?). It's meaningless that there's no clear version that POSIX should standardize on – GNU `which` is the de facto standard on Linux. Debian is hardly going to ship FreeBSD's `which`, as even the disc…

[deleted]

Re: Which is not Posix

#36
post #26

Earlier quoted context omitted.

As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?). As for systemd, AFAIK system startup isn't covered by POSIX at all, so bsd init, sysv init and systemd are all equally not covered by POSIX. Which is fine, POSIX was never meant to cover every sing…

> As the Debian brouahaha pointed out, there are multiple incompatible implementations of which, so it's unclear which one (ha ha) POSIX should standardize on (and is it politically realistic to anoint one as the 'winner'?). It's meaningless that there's no clear version that POSIX should standardize on – GNU `which` is the de facto standard on Linux. Debian is hardly going to ship FreeBSD's `which`, as even the disc…

> GNU `which` is the de facto standard on Linux

Well, no, even on Linux there's no de facto standard. Fedora/RHEL use GNU which, but Debian-derived distros use the debianutils which, which is not the same as GNU which.

> POSIX doesn't cover init, but it does cover many other system calls and behaviours that systemd explicitly rejects

Interesting. Can you be a bit more specific? What in POSIX does systemd explicitly reject? And might there be a reason for that?

Re: Which is not Posix

#37
post #4

Earlier quoted context omitted.

command is a bash builtin. /usr/bin/command is a bash script that calls into the builtin command. If you just run `command`, you are running the builtin function and not the /usr/bin/command file. Try running `command -V command` and `command -V /usr/bin/command`

Point being, it doesn't help you finding /usr/bin/command via regular search in PATH and it reports the builtin instead.

Isn't reporting the builtin the best behavior, since that's what will run if you type `command`?

Re: Which is not Posix

#38
`which(1)` probably needs maintenance no more than once a decade, and all talk of removing it has already cost the Debian `which(1)` maintainer alone more than the savings of several centuries' worth of maintenance on `which(1)` Actually removing it will cost even more still in maintenance cost for third parties that depend on `which(1)` today.

This utter lack of respect for other people's time on the part of the Debian community is simply shocking.

We, the users, would understand this if `which(1)` maintenance were a burden on the Debian maintainers, but it is not.

Respect our time!

Re: Which is not Posix

#39
So, is there a distribution that is POSIX, and nothing else, both in commands and API?

Would be fun to have (in a VM; I guess it would be too annoying to use as one’s main system), for compatibility testing.

Re: Which is not Posix

#40
post #29

Linux from Scratch has a very tiny implementation suitable for all systems that have bash installed: #!/bin/bash type -pa "$@" | head -n 1 ; exit ${PIPESTATUS[0]} Just save it as which, chmod +x and add to path. https://www.linuxfromscratch.org/blfs/view/svn/general/which...

Not all systems have bash as /bin/bash. A shebang line of '#!/usr/bin/env bash' would be even more portable.
Post reply on HN