11 ms·
Which is not Posix
- cryptonector 5y agohttps://news.ycombinator.com/item?id=29026623 https://news.ycombinator.com/item?id=29026623
- tptacek 5y agoYeah, no thanks, I'm going to keep using `which`, and distributions are going to support it, no matter how "standard" `command -v` is. The only reason we're talking about this is that it's so noteworthy that any distro would seriously suggest people avoid `which`, which is the de facto standard.
- chasil 5y agoBusybox also supports both variants, which is nice. C:\Users\luser>busybox64 sh ~ $ command -v ssh C:/WINDOWS/System32/OpenSSH/ssh.exe ~ $ which ssh C:/WINDOWS/System32/OpenSSH/ssh.exe ~ $ exit
- GauntletWizard 5y agoBusybox supports may subcommands, and on systems based on it virtually every common command is aliased to it, but nice isn't included. which which /bin/which which nice So, no, `which` is not `nice` :). Edit: I just pulled the the latest dockerhub image, and nice is one of the included applets. So if you really want which to be nice, upgrade busybox.
- oweiler 5y agoThere are enough dists which don't support which.
- coldtea 5y agoAny that more than 10 people use?
- Seirdy 5y agoThe 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.
- maxnoe 5y agoArch uses zsh in the Installation Medium and bash as default shell of the code System, both have which as a builtin function.
- mistersquid 5y agomacOS Catalina 10.15.7 $ command -v command command vs $ which command /usr/bin/command
- dahfizz 5y agocommand is a bash builtin. /usr/bin/command is a bash script that calls into the builtin command. If you just run `command`, you are running the builtin function and not the /usr/bin/command file. Try running `command -V command` and `command -V /usr/bin/command`
- steerablesafe 5y agoPoint being, it doesn't help you finding /usr/bin/command via regular search in PATH and it reports the builtin instead.
- joemi 5y agoIsn't reporting the builtin the best behavior, since that's what will run if you type `command`?
- pxc 5y agoNo. 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.
- SAI_Peregrinus 5y agoExactly. I've been troubleshooting updating some libraries on an embedded system recently, and running a lot of `/lib/ld-linux.so --list "$(which <executable>)"` on various things to figure out what `-rpath`s I need to pass to the linker. I want the command to fail if I give it a builtin or alias! Other times I want to use `command`: most often to bypass an alias, but with `-v` mode it's handy to get the definition of an alias. I suppose `find "$PATH" -name NAME` is roughly equivalent to `which NAME`.
- jmclnx 5y agoI do not understand this Debian 'which' kerfuffle, but seems a big argument over nothing. But for me, 'type' is my go to in scripts. And as a tcsh user, I never knew 'which' was a thing in Bourne shells until I checked a few minutes ago. I do not know when it appeared, but I thought in the 'old days' 'which' was specific just to [t]csh. Also, I never heard of 'command -v' until I saw it in LWN a few days ago :)
- aidenn0 5y agowhich is not a thing in bourne shells; it's a separate executable. If it were a builtin then there wouldn't be a kerfuffle; there are multiple implementations of "which" and Debian doesn't want to privilege one of them, but if Debian base scripts use one, then it must privilege one of them.
- shadowgovt 5y agoIn this case, the simplest solution is to probably privilege one of them and then everybody get back to work.
- yakubin 5y agoIt is a built-in in zsh. Thanks to that, it will recognize when something is a built-in, an alias, a function or a command and report accurately what will be executed when you type it in without the "which".
- pxc 5y agoThat's what `type` (or in zsh, `whence`) is for. Aliasing `which` just makes the behavior of running `which` slightly less predictable, and if what you actually want is the behavior of the `which` program, you then need to (know to) run `command which` instead.
- marcosdumay 5y ago> and Debian doesn't want to privilege one of them Any reason for that? Insisting on not choosing a preferred set of software seems like a really bad decision for a distro.
- msbarnett 5y agoNot 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 agoSo… bike shedding?
- buserror 5y agoExactly 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 agoAs 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.
- kevincox 5y agoBased on the title I was thinking this was a quiz. I am imagining a game where it shows two shell snippets and you need to select the one that works correctly under a strict POSIX environment.
- steerablesafe 5y agoOK, I don't get `command`. When I run `command time -v sleep 10` it clearly runs /usr/bin/time on my system (the bash builtin doesn't have the -v option), but if I run `command -v time` it outputs `time`, corresponding to the builtin. How is this helpful? Also shouldn't `command` and `command -v` find the same things? edit: Well apparently this is the standard behavior [1]. So lookup is not the same for `command <name>` vs `command -v <name>`, and there doesn't seem to be a standard way to lookup the executable started by `command <name>`. `which` seem to fill that gap. [1] https://pubs.opengroup.org/onlinepubs/007904975/utilities/command.html https://pubs.opengroup.org/onlinepubs/007904975/utilities/co...
- kevin_thibedeau 5y agoIf only there was a functioning standards body that could add a new option to command that reported this sort of info.
- throwaway20371 5y agoI've always used whereis instead of which anyway. More useful info out of one command.
- vimsee 5y agoSay 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.
- pxc 5y agoI 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.
- rezonant 5y agoI 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 :-)
- ape4 5y agoSeems like `which` should be added to POSIX
- kj4ips 5y agoI remember being bitten my `which` on Solaris not giving return codes. I was not yet aware of `hash` or `command` At $PREVIOUS_JOB, I tried to maintain dotfiles that could be used on Solaris and RHEL interchangably, and I had a bunch of conditionals for enabling various completions.
- cf100clunk 5y agoDiscussed at length previously here: https://news.ycombinator.com/item?id=29026623 https://news.ycombinator.com/item?id=29026623
- jcelerier 5y agolet's collectively mark POSIX as deprecated and move on
- goohle 5y agoIt's better to create a «PWG» (POSIX Working Group), which then publish POSIX2021, POSIX2026, and so on.
- throw0101a 5y agoThis already exists: * https://en.wikipedia.org/wiki/Austin_Group https://en.wikipedia.org/wiki/Austin_Group * https://www.opengroup.org/austin/ https://www.opengroup.org/austin/ * https://www.austingroupbugs.net/main_page.php https://www.austingroupbugs.net/main_page.php * https://www.mail-archive.com/austin-group-l@opengroup.org/maillist.html 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://unix.org/ * https://twitter.com/unixr https://twitter.com/unixr
- jandrese 5y agoThe 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.
- orhmeh09 5y agoPlease don’t call it brain damage. It’s unfair to the human beings who aren’t responsible for the mess of POSIX.
- BiteCode_dev 5y agoWho cares? When I want to know where my python comes from, I which it. Oh, that's the virtualenv, thanks. Unless you doing alternative micro meta alpine docker images, this has no importance whatsoever.
- deleted 5y ago[deleted]
- mike256 5y agoLinux 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.html https://www.linuxfromscratch.org/blfs/view/svn/general/which...
- Athas 5y agoNot all systems have bash as /bin/bash. A shebang line of '#!/usr/bin/env bash' would be even more portable.
- richardwhiuk 5y agoNot all systems have env has /usr/bin/env.
- pxc 5y agoThe presence of the env command is required by POSIX, and /usr/bin/env is the closest thing we have to a standard path for it.
- richardwhiuk 5y ago/bin/bash is the closest thing we to a standard path for bash.
- IggleSniggle 5y agoI like bash 4+ for associative arrays, and use it on macOS. But macOS is still v3 by default (for /bin/bash). I think `/usr/bin/env bash` is a great shebang, for the record, but I'm not totally convinced that it's more portable than `/bin/bash`. Can you explain what makes it actually more portable? In absence of that, you might actually expect `/bin/bash` to be more portable, as at least you can more likely make assumptions based on the OS.
- 5y ago
- amelius 5y agoWhy does "which" not show me aliases in Bash?
- cryptonector 5y ago`which(1)` probably needs maintenance no more than once a decade, and all talk of removing it has already cost the Debian `which(1)` maintainer alone more than the savings of several centuries' worth of maintenance on `which(1)` Actually removing it will cost even more still in maintenance cost for third parties that depend on `which(1)` today. This utter lack of respect for other people's time on the part of the Debian community is simply shocking. We, the users, would understand this if `which(1)` maintenance were a burden on the Debian maintainers, but it is not. Respect our time!
- Someone 5y agoSo, is there a distribution that is POSIX, and nothing else, both in commands and API? Would be fun to have (in a VM; I guess it would be too annoying to use as one’s main system), for compatibility testing.
- racingmars 5y agoNot a Linux distribution, but the Unix implementation in z/OS, IBM's mainframe operating system, is painfully POSIX-compliant.
- donatj 5y agoWhat 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.
- asveikau 5y agoI 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.
- bruce343434 5y agoHonestly, who cares? Why care? I do not understand this drama.
- yjftsjthsd-h 5y agoObviously the kind of people involved in putting together a distro do, and should, care.
- avgcorrection 5y agoWhich what is not Posix? Oh. What a confusing title. This would have been so much clearer: which(1) is not Posix
- jfrunyon 5y ago> Use command -v instead Huh? That's a shell builtin, not an executable. That's next to useless. > which is widespread but not standardized What can possibly need standardization about "prints the full path to a command"??? > which in its barest form fails to handle builtins and aliases Yes, because it's an executable, not a builtin. This means that it is usable from outside of a shell, which is quite a significant benefit. Additionally, there is no path to a builtin or alias - so it actually handles both how it says on the tin: it returns no path. Moreover, it's rarely useful to check for a builtin or alias from a non-interactive context. > Just compare the arguments of the most common ones I have literally never once had to pass a single argument to which, except the name of a command. At which point it has literally always given me back the path to that command (or nothing). But, let's compare, shall we? - All 4 implementations support `which which`, with identical semantics - All 4 implementations support `which -a which`, with identical semantics - 2 implementations support no other options - 1 implementation has a -s flag for silent operation, which can be portably replaced by redirecting output. - 1 implementation has many more options... which appear to mostly be useful interactively. I'm not sure why this implementation is presented as "GNU"; the linked page clearly attributes it to a "Carlo Wood" > For scripts, command -v is better, because it’s simpler and machine-readable. I strongly doubt that `command -v` actually does what the author wants it to do. I can't imagine why you would want to end up with the string "alias ls='ls --color=auto'" in your variable when you were looking for "/bin/ls", as `which` would return.
- hynek 5y agoI'm super confused by the hostility of this comment. The TIL post was just a summary of a drama that almost removed which from debian and the lessons learned from it about the guarantees and portability of which (none), and how to prevent problems in the future. You can freely choose that the problems don't apply to you, and you can be angry at POSIX and/or Debian for whatever happened or not as many others in this comment section. But I don't understand why you chose to write a belligerent comment as if any of it is the author's (yes me, but I didn't submit it to HN) fault or as if he is arguing in front of a committee to take it away from you. As for Carlo Wood: https://savannah.gnu.org/projects/which https://savannah.gnu.org/projects/which links to http://www.gnu.org/software/which/ http://www.gnu.org/software/which/ that in turn links to https://carlowood.github.io/which/ https://carlowood.github.io/which/. Maybe do your research if you want to be a pedant?
- fsckboy 5y agoaw, title! don't capitalize the W, that is really not unix i thought this was going to be a little quiz of which things are and are not POSIX