5 ms·

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

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 justification for removing it from Debian – this whole drama is just pointless pedantry over something precisely because it is so low stakes.

CSSer 5y ago
So… bike shedding?
- buserror 5y ago
  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.
jabl 5y ago
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 single behavior of an OS, but rather a sort of least common denominator to make porting easier (not "make porting non-existent").
- msbarnett 5y ago
  > 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
- tannhaeuser 5y ago
  FYI: LSB [1] is/was the ISO-sanctioned Linux standardization effort, on top of and beyond POSIX/SUS. But it hasn't caught up with recent major changes such as systemd, namespaces/Docker, io_uring, etc. and nobody really seems to care anymore. [1]: https://en.m.wikipedia.org/wiki/Linux_Standard_Base https://en.m.wikipedia.org/wiki/Linux_Standard_Base
- jfrunyon 5y ago
  > incompatible How?
deleted 5y ago
[deleted]
AceJohnny2 5y ago
> just pointless pedantry over something precisely because it is so low stakes. You have defined Bikeshedding ;) https://thedecisionlab.com/biases/bikeshedding/ https://thedecisionlab.com/biases/bikeshedding/
jonnycomputer 5y ago
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
- sigzero 5y ago
  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".
  - jonnycomputer 5y ago
    I suspected it might, but was too lazy to check. Thanks for doing that.
- jfrunyon 5y ago
  Correct, because they do two different things. `which` is a standalone executable which searches the environment's PATH for the named command. It doesn't know about commands which aren't executables (i.e. builtins and aliases). `command` is a shell builtin which tells you exactly what that shell in its current state would run.
  - jonnycomputer 5y ago
    Interesting, and useful to know. Thanks for that.
phil294 5y ago
Honest question, if POSIX is not relevant anymore, why haven't wee seen a user-friendly set of command line tools come out yet?
- effie 5y ago
  POSIX isn't very relevant, but the set of basic Linux tools with generally expected features and behaviour is. The difference is that the latter evolves. For example, when GNU tools appeared, people started to prefer them to POSIX tools, because the GNU tools had useful extensions. POSIX never catched up. So we have seen more friendlier set of tools than POSIX would force on us, but it was evolution, not revolution. Why, maybe because people see value in continuity and acquired knowledge and don't want to start using obscure new tools like ag or exa, even if they could be superior.

CSSer 5y ago

So… bike shedding?

buserror 5y ago
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.

jabl 5y ago

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 single behavior of an OS, but rather a sort of least common denominator to make porting easier (not "make porting non-existent").

msbarnett 5y ago
> 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
tannhaeuser 5y ago
FYI: LSB [1] is/was the ISO-sanctioned Linux standardization effort, on top of and beyond POSIX/SUS. But it hasn't caught up with recent major changes such as systemd, namespaces/Docker, io_uring, etc. and nobody really seems to care anymore. [1]: https://en.m.wikipedia.org/wiki/Linux_Standard_Base https://en.m.wikipedia.org/wiki/Linux_Standard_Base
jfrunyon 5y ago
> incompatible How?

deleted 5y ago

[deleted]

AceJohnny2 5y ago

> just pointless pedantry over something precisely because it is so low stakes. You have defined Bikeshedding ;) https://thedecisionlab.com/biases/bikeshedding/ https://thedecisionlab.com/biases/bikeshedding/

jonnycomputer 5y ago

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

sigzero 5y ago
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".
- jonnycomputer 5y ago
  I suspected it might, but was too lazy to check. Thanks for doing that.
jfrunyon 5y ago
Correct, because they do two different things. `which` is a standalone executable which searches the environment's PATH for the named command. It doesn't know about commands which aren't executables (i.e. builtins and aliases). `command` is a shell builtin which tells you exactly what that shell in its current state would run.
- jonnycomputer 5y ago
  Interesting, and useful to know. Thanks for that.

phil294 5y ago

Honest question, if POSIX is not relevant anymore, why haven't wee seen a user-friendly set of command line tools come out yet?

effie 5y ago
POSIX isn't very relevant, but the set of basic Linux tools with generally expected features and behaviour is. The difference is that the latter evolves. For example, when GNU tools appeared, people started to prefer them to POSIX tools, because the GNU tools had useful extensions. POSIX never catched up. So we have seen more friendlier set of tools than POSIX would force on us, but it was evolution, not revolution. Why, maybe because people see value in continuity and acquired knowledge and don't want to start using obscure new tools like ag or exa, even if they could be superior.