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

71–80 of 97 posts

Re: Which is not Posix

#71

Post by pxc »

joemi wrote: post #37
steerablesafe wrote: post #7

Earlier quoted context omitted.

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

No. There is no ‘best behavior’.

If your aim is to discover which piece of software provides an executable you know you're running, whether it's wrapped by an alias or not, you want the behavior of `which`, and the behavior of `command -v` won't help you.

If your aim is to discover what will run when you type a command in your shell, the behavior of `command -v` (or `type`) is what you want, and the `which` program won't help you.

Re: Which is not Posix

#72

Post by pxc »

vimsee wrote: post #34
throwaway20371 wrote: post #11

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.

I use that all the time!

It's also useful if you want to find out where an executable lives when the thing on your PATH is a symlink (sometimes to another symlink, and so on). With GNU coreutils and which, you can run:

  realpath $(which python)
  realpath $(which php)
and so on, in order to start tracking down what package (if any) owns the interpreter on your PATH, or if it belongs to some other management tool, etc. This gives you slightly different information than something like `php --version`.

It's really useful on NixOS, too, since you might have multiple versions of the same package living in your /nix/store, and you want to know which one is the one you're using.

Re: Which is not Posix

#74

Post by pxc »

maxnoe wrote: post #70
pxc wrote: post #56

Earlier quoted context omitted.

Except the behavior of the builtin is not the same as the behavior of the program, and Arch's base package doesn't include the which command.

It's part of base-devel. https://archlinux.org/groups/x86_64/base-devel/

Thanks for pointing that out! I'll add it to my pacstrap invocations in the future.

Re: Which is not Posix

#75

Post by rezonant »

throwaway20371 wrote: post #11

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

I used to use whereis, and... somewhat ironically... switched to using 'which' because it was more likely to be available on whatever given Linux environment I was using :-)

Re: Which is not Posix

#76

Post by jbovlaste »

orhmeh09 wrote: post #57
msbarnett wrote: post #41

Earlier quoted context omitted.

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

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?

Ubuntu made the switch to dash back in 2006 to decrease boot times, as dash is much faster than bash. This was upstreamed to Debian. POSIX compatibility made the transition easier (as most scripts were made to run on many Unix systems, not just Linux), but was not the motivation for the switch.

https://wiki.ubuntu.com/DashAsBinSh

Re: Which is not Posix

#77

Post by phil294 »

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…

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

Re: Which is not Posix

#79

Post by tannhaeuser »

jabl wrote: post #26
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…

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…

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

Re: Which is not Posix

#80

Post by mjw1007 »

orhmeh09 wrote: post #57
msbarnett wrote: post #41

Earlier quoted context omitted.

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

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?

As I understand it, the main motivations were speed and memory footprint. Might not matter too much on a desktop, but people also use Debian for smaller things like Freedombox.
Post reply on HN