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?
The project specifically rejects "caring about POSIX" in its entirety. Poettering has discussed this at length[1].
I'm not criticizing systemd here, I'm merely pointing out that Debian is already perfectly fine with shipping non-portable, aPOSIX or even anti-POSIX software by default (which I think is fine), and that the sudden pearl-clutching around `which` not being POSIX is completely inconsistent with many other decisions the project makes and has made.
[1]: https://archive.fosdem.org/2011/interview/lennart-poettering...
"In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!"
The interview notes various POSIX-incompatibilities as they existed in 2011. They have grown enormously since. It surfaces in userland in a huge number of ways, and *BSD ports maintainers have noted that it's increasingly hard to port any number of things due to the systemd-isms (which now extend to logging, cron, home directories, and many other core functionality replacements) they're baking in.
Again, this is not intended to criticize systemd, but this is precisely the sort of effect that people are hand-wringing about wrt `which` in bash scripts, but nobody is insisting that systemd needs be removed from Debian for having similar POSIX portability impacts. POSIX compatibility has simply never been a meaningful goal of Debian
Honest question, is any of this relevant? It's a mystery to me why anyone would care as long as it gets the job done. Anyone wanting something else can go ahead and use it. Put differently: it would make no difference to anyone currently using command -v. If the Debian devs have a time machine, they can go back to the start and change the course of history. Otherwise none of the discussion around this issue makes sense.
These are all the POSIX standardized commands:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/
It's also interesting that POSIX specified a job queue environment that nobody seems to use (entry with the qsub command), separate from the simple job system that originated in Bill Joy's C shell. The systemd oneshot service modifier comes to mind as an alternative to qsub.