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

Which is not Posix

hynek.me

Post reply on HN
Print view View original

41–50 of 97 posts

Re: Which is not Posix

#41

Post by msbarnett »

jabl wrote: post #36
msbarnett wrote: post #31

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'?). 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 r…

> 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

Re: Which is not Posix

#42

Post by chasil »

jabl wrote: post #36
msbarnett wrote: post #31

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'?). 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 r…

The one that comes to my mind is crontab, [which can be] replaced by timer units.

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.

Re: Which is not Posix

#44

Post by richardwhiuk »

Athas wrote: post #40
mike256 wrote: 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.

Not all systems have env has /usr/bin/env.

Re: Which is not Posix

#45

Post by jandrese »

throw0101a wrote: post #30
goohle wrote: post #25

Earlier quoted context omitted.

It's better to create a «PWG» (POSIX Working Group), which then publish POSIX2021, POSIX2026, and so on.

This already exists: * https://en.wikipedia.org/wiki/Austin_Group * https://www.opengroup.org/austin/ * https://www.austingroupbugs.net/main_page.php * https://www.mail-archive.com/austin-group-l@opengroup.org/ma... There are drafts available for a 202x revision (have to register an account). See also: * https://unix.org/ * https://twitter.com/unixr

The problem with POSIX is that they don't work to define the fundamental necessities of a good OS, they merely document the cases where most of the distros have the same functionality with the same syntax.

This ends up being only a subset of the typical functionality found on a system. Even worse is the way they can lock in old braindamage and make it harder to fix.

Re: Which is not Posix

#46

Post by donatj »

What would it take to get `which` on a fast track to POSIX-dom?

It's still a living standard right? `which` seems like one of the first command any *NIX user learns. It should be standardized.

Re: Which is not Posix

#47

Post by jonnycomputer »

msbarnett wrote: post #8

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…

On Mac, with an alias I don't get the same answer from the two anyway:

  $ command -v emacs
  alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw "$@"'

  $ which emacs
  /opt/local/bin/emacs

Re: Which is not Posix

#48

Post by asveikau »

I wonder what version of POSIX "command -v" conforms to, and if which might have become widespread before it.

[Edit: * Some googling suggests maybe this made it into posix circa 1995? Base specification issue 4.

* Wikipedia says which came about in 3BSD which was from the late 70s -- OpenBSD manpage also says this.

* My FreeBSD machine's manpage says FreeBSD 2.1 which is also 1995.]

I have an old Solaris box I don't power on, which I purchased for the novelty more than 20 years ago. It has which. Its semantics are slightly different from a typical Linux or *BSD implementation, but it's there.

Re: Which is not Posix

#49

Post by sigzero »

jonnycomputer wrote: post #47
msbarnett wrote: post #8

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…

On Mac, with an alias I don't get the same answer from the two anyway: $ command -v emacs alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw "$@"' $ which emacs /opt/local/bin/emacs

That happens on every system I believe. It does for my RHEL boxes anyway. That also isn't the behavior I am looking for so I will stick with "which".

Re: Which is not Posix

#50

Post by Seirdy »

coldtea wrote: post #28
oweiler wrote: post #23

Earlier quoted context omitted.

There are enough dists which don't support which.

Any that more than 10 people use?

The Fedora base image does not include which. The base image is what's used in the standard OCI Fedora container, some Flatpak work, and some other things.

Arch also doesn't include "which", nor do some arch-based distros.

Post reply on HN