5 ms·

> 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 (

> 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.

deleted 5y ago
[deleted]
jabl 5y ago
> 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?
- msbarnett 5y ago
  > 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.html 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
  - orhmeh09 5y ago
    If Debian is perfectly fine with anti-POSIX, why go to the effort of making and switching to dash over bash? One of the impetuses for that project was bash’s inability to confirm to posix even when launched in posix mode. What’s that about?
    - deleted 5y ago
      [deleted]

deleted 5y ago

[deleted]

jabl 5y ago

> 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?

msbarnett 5y ago
> 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.html 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
- orhmeh09 5y ago
  If Debian is perfectly fine with anti-POSIX, why go to the effort of making and switching to dash over bash? One of the impetuses for that project was bash’s inability to confirm to posix even when launched in posix mode. What’s that about?
  - deleted 5y ago
    [deleted]