23 ms·

Debian's Which Hunt

• fractalb 5y ago
  I don't really understand what the need is to kill off `which` command. Is it a maintenance burden?
  • nikanj 5y ago
    People pick the weirdest hills to die on, and in open source we can see it happen in real time. If this happened inside a big corp, we’d never see one stubborn maintainer getting overruled by their peers / bosses.
• luord 5y ago
  Duly noted: get used to `command -v` Better to follow standards anyway.
• machinesbuddy 5y ago
  TIL about `command -V` (the verbose flag)!
• egberts1 5y ago
  also - ‘which’, being too Debian-specific, will not return the filespec if its file permission is too restrictive. - ‘command -v’, also will not display binary if its file permission is too restrictive. - ‘whereis -b’ works just fine as long as /usr/sbin has world RX file mode or other lesser matching filemods. Still stuck on ‘whereis’
• dilawar 5y ago
  'command -v' is POSIX!! I have always avoided it in favor of which because its output doesn't feel machine friendly.
  • Taywee 5y ago
    What's not machine-friendly about `command -v`'s output? Can you not just use the exit status? Or did you mean that you avoid `which` in favor of `command -v`?
    • guerrilla 5y ago
      See my post above.
    • goohle 5y ago
      $ which true /usr/bin/true $ command -v true true $ which ls /usr/bin/ls $ command -v ls alias ls='ls --color=auto'
      • Taywee 5y ago
        In this case, `which` is just searching the `PATH` and not telling you what will actually run. `command` is correctly informing you of the whole story. I'll add that `which` on my setup is using the zsh built-in, which also informs of aliases and built-ins. So yes, that's more useful if you're using `which` to determine "Does this name exist as an executable anywhere in the PATH", but most people use it to mean "What will actually be executed if I run this word as a command?" edit: Or, most often in scripts, it's used just for its exit status to tell whether the command exists to be executed at all.
        • marcosdumay 5y ago
          > `command` is correctly informing you of the whole story. You are assuming a bit too much here. Which tells you the preferred executable with that name, while command tells you what will run if you execute it on the current shell. From what I can tell, one does not replace the other. But yes, for your example of usage, command is more correct.
      • deleted 5y ago
        [deleted]
      • anderskaseorg 5y ago
  • simias 5y ago
    I learned about `command -v` just now reading this article. I only knew of `which` and `type` (as well as the very convenient `=executable` syntax that expands to the path of the binary, but I think that's a zsh-ism). What makes `command -v` not machine friendly? It seems to always output just the PATH, unlike type which tries to be human friendly.
    • guerrilla 5y ago
      It's pretty much useless for the same purpose: $ which ls /usr/bin/ls $ type ls ls is aliased to `ls --color=auto' $ command -v ls alias ls='ls --color=auto' Suddenly I find myself irritated at Debian despite not even using it. Why would they not just include the GNU one?
      • jwmhjwmh 5y ago
        I think aliases are only used in interactive shells: $ sh -c 'command -v ls' /bin/ls
      • scbrg 5y ago
        This is a very unlikely output when run from a script using the /bin/sh interpreter on Debian, though. If that is the output you've gone out of your way to create an alias in a script, in which case it's reasonable output. It is what will happen when the script runs that command, after all.
        • guerrilla 5y ago
          I'm certain there's masses of code that depends on `which` responding the way it does and scripts with aliases in them regardless of whether that was the right way to do it or not, so your point is probably irrelevant in the grand scheme of things. Think about all that enterprise install and setup crap. People still depend on that spaghetti trash working.
      • Taywee 5y ago
        That depends on whether your shell has a built-in which or not. Mine says % which ls ls: aliased to /bin/ls --color=auto Which makes way more sense. Your "which" is not telling you what will actually be executed when you run the `ls` command there. `command`, on the other hand, is guaranteed to be a built-in, has consistent behavior, and has defined, consistent output, unlike `which`. What `which` outputs will be different depending on shell and what implementation of `which` you actually have installed.
  • mshockwave 5y ago
    I noticed that on Ubuntu at least, `command -v` has the same output format of `which`, where `command -V` does not. Did you accidentally use the latter one?
    • deleted 5y ago
      [deleted]
  • nonameiguess 5y ago
    shellcheck throws a lint error if it finds you using which and tells you to use 'command -v' instead.
    • hdjjhhvvhga 5y ago
      Thank you for reminding me about this neat tool, it saved my ass a couple of times.
    • sigzero 5y ago
      I just tried it on the shellcheck site. It didn't flag it.
  • Enginerrrd 5y ago
    What a mess. It sounds like command -v should have been the default from the get go and which should never have been introduced to debianutils. Once it was though, IMO, debian should never make a decision that breaks existing functionality. In general, I don't care if you extend features beyond POSIX in your core utilities, but once you do, you have to assume people rely on that functionality. I think this is the most poignant take: >A proper transition plan would mean that I would never even notice this. One which would replace another and nothing would break. That is the sort of thing I expect to happen in Debian - we are generally good at this stuff, and it's a big reason for using the distro.
    • chasil 5y ago
      I am fairly certain that which came first. This is the POSIX specification for command: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
      • Taywee 5y ago
        Notable sections from that page: > The command -v and -V options were added to satisfy requirements from users that are currently accomplished by three different historical utilities: type in the System V shell, whence in the KornShell, and which in the C shell. Since there is no historical agreement on how and what to accomplish here, the POSIX command utility was enhanced and the historical utilities were left unmodified. The C shell which merely conducts a path search. The KornShell whence is more elaborate-in addition to the categories required by POSIX, it also reports on tracked aliases, exported aliases, and undefined functions. > The output format of -V was left mostly unspecified because human users are its only audience. Applications should not be written to care about this information; they can use the output of -v to differentiate between various types of commands, but the additional information that may be emitted by the more verbose -V is not needed and should not be arbitrarily constrained in its verbosity or localization for application parsing reasons.
        • denton-scratch 5y ago
  • anonydsfsfs 5y ago
    "command -v" in Dash (the Debian shell) has a serious bug that makes it non-POSIX compliant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264
    • lucb1e 5y ago
      To be honest it's kind of weird to have things in your PATH that are not meant to be executed, so I'm not sure I agree about it being that important and it doesn't seem to have gotten any attention since 2017 despite a patch being available, but I take your point that this should not happen and is of course noncompliant.
  • wahern 5y ago
    If you're parsing the output of `command -v`, you're doing it wrong: if command -v foo >/dev/null; then foo ... else bar fi From shell scripts it doesn't matter if foo is an alias because if it is an alias, it's one that the script created itself. For interactive use, just go ahead and use which if that's what you like. Most people will be using bash or z-shell or whatever, and portability isn't a concern. Interactive shell usage and shell scripting are quite distinct. Yes, there's a huge overlap, but as in any other language, when you're writing a properly structured program (not a one-off or hack), you're expected (for good reasons) to follow more consistent rules and conventions.
  • pmontra 5y ago
    I'm not sure I knew about type. I didn't know about command -v probably because I learned which close to 35 years ago and I didn't have to look for a different way to do it.
• vidanay 5y ago
  Wow, talk about a tempest in a tea kettle. Bikeshedding like this is why Linux will never achieve any significant market share for average consumers. (Because all that mental effort could have been spent on solving some real problem instead of philosophical conformity.)
  • peatmoss 5y ago
    As a counterpoint, users can get very wrapped up in changes, and it sounds like the Debian project had a mechanism for resolving the conflict that wasn’t “endless flamewar.”
  • jasonjayr 5y ago
    Bikeshedding like this must constantly go on on large teams internally, especially with technical leads on what the scope and how their particular part of the system functions. Since Debian does this all out in the open, we just get to watch how the sausage is made.
  • emptyparadise 5y ago
    Big opaque corporations definitely never spend way too much time in meetings over pointless things.
    • dyingkneepad 5y ago
      And most Open Source contributions to widely used projects come from people working on such corporations, being paid to do Open Source.
  • ptero 5y ago
    > Bikeshedding like this is why Linux will never achieve any significant market share for average consumers. In my opinion, this is a good thing. Aiming for increasing "market share for average consumers" usually implies focusing on the standard baseline of functionality. There is nothing wrong with this, but this invariably cuts off tinkerers and enthusiasts who care about playing with SDRs and LIDARs and other fringe capabilities as much as (and usually more than) they care about the simplicity of the WiFi setup. For simplest possible internet browsing there is ever-simpler Windows, with its design choices such as sharing of WiFi access and creeping ads. Just my 2c.
• emptyparadise 5y ago
  Seems like this is a case of Debian governance working as designed. I'm surprised that 'which' isn't POSIX though.
  • wutbrodo 5y ago
    Absolutely. Transparent governance is really hard, and it was quite nice to see an example of a conflict handled and resolved so well, right out in the open.
    • denton-scratch 5y ago
      Not like systemd, then. [Edit] I didn't mean the systemd thing lacked transparency; I just mean the result wasn't "nice".
      • marcosdumay 5y ago
        The systemd thing was extremely transparent. It didn't reach a solution that satisfied everybody, but there wasn't any secrecy on it.
        • denton-scratch 5y ago
          Yes. I have no gripe about the process. (Well, I don't think it was a technical decision, so it shouldn't have been dumped on the TC). It was pellucidly transparent. Exemplary, really. I just really don't like systemd, so I'm sorry that it became the Debian default init. My gripe is with the outcome, not the process. Most package-maintainers must have disagreed with me. It's OK, I'm used to people not agreeing with me. /me still a Debian user, with sysvinit.
          • tannhaeuser 5y ago
            Out of interest, are you using Devuan or other Debian distro specifically designed to be systemd-free?
• stonogo 5y ago
  I find it interesting that Debian even cares whether 'which' is POSIX or not, given that they don't ship a lot of POSIX commands (e.g. 'ed' and 'bc') by default. It seems to me much of the value in such a standard is you can either rely on it or not; deliberately omitting some of the specified utilities, then using other utilities as arguments in a systems architeecture discussion seems like a self-contradiction. Unfortunately the Debian wiki entry on POSIX merely defines it and doesn't enlighten us as to policy decisions.
  • denton-scratch 5y ago
    Debian's a bit funny. Maintainers tinker with packages more often than I'd like; they make changes to packages that already work perfectly well, and sometimes breakage occurs. This is partly because of the autonomy that Debian package maintainers enjoy. I have slightly mixed feelings about that - but only slightly. I'd sooner have maintainer autonomy, and seriously-distributed decision making, than an overlord.
• nonameiguess 5y ago
  > The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job". While I can understand having this attitude, a whole lot of package build scripts, not just in Debian, but in the upstreams, rely upon which existing and printing out the path of an executable without a deprecation warning. I would expect a Debian maintainer to realize that. Debian does patch the heck out of upstream packages, but they don't provide everything, and all Debian users are not going to want to go to equal effort to patch all of the build files for packages Debian doesn't provide.
  • shadowgovt 5y ago
    As a political note: saying something like that is a great way to guarantee that if you want to remove `which`, you likely now have a set of engineers who will oppose your attempts to do so. Those kinds of attitudes pushed me out of open-source engineering and into closed-source, commercial engineering, purely because it's nice to have a boss who can say "Don't talk to your peers like that; it's counterproductive" with some authority.
  • sixothree 5y ago
    Wait. Is the problem here extra _text_ in the output that shouldn't be parsed? I cannot believe people are parsing text output from other commands in the year 2021. To me that this sounds like incredibly unsafe practice and am just astounded it happens.
    • richardwhiuk 5y ago
      Parsing the bytestream output of another program is the unix way.
      • sixothree 5y ago
        I get that. I'm just surprised it's still considered acceptable. I feel like even simple JSON would be a better output. Sure, humans would have a problem reading it but that's what shells are for.
• soraminazuki 5y ago
  Searching the Nix package repository can give you a good idea of how prevalent some software are used as a dependency because Nix packages requires all dependencies to be explicitly specified by design. Now, a quick search for "which" yields 2.5k hits [1]. Although a non-negligible portion of hits are just common uses of the word "which" in code comments, the other large portion of the hits are indeed dependencies on the "which" package. Although the use of the "which" command might potentially be fragile when considering cross-platform use, it seems like a really bad idea to deprecate it from a pragmatic point of view. [1]: https://github.com/NixOS/nixpkgs/search?l=Nix&q=which https://github.com/NixOS/nixpkgs/search?l=Nix&q=which
• deleted 5y ago
  [deleted]
• pornel 5y ago
  I'm a descriptivist when it comes to standards. When everyone uses `which`, POSIX should add it. "but it's non-standard!" can be fixed by making it a standard.
  • Taywee 5y ago
    The problem is that `which` behaves differently in many different existing use-cases (sometimes reporting aliases and sometimes not). If POSIX defines the behavior, then many existing uses become non-standard, and the existing implementations have to decide to change to become standard and possibly break backward compatibility or remain the same and stay non-standard.
    • guerrilla 5y ago
      In that case, pick the system which is statistically dominant and clone that. That'd be GNU first and FreeBSD second. The standard can be some subset of their behavior.
      • capableweb 5y ago
        Or, add a new standard describing the wanted behavior from `which` which everyone is already using, but put it under a new binary name. If it's supposed to show the path for the thing passed in, maybe `where` would make sense.
        • ketralnis 5y ago
          A standards descriptivist is unlikely to agree with "make a new standard so everybody has to change their behaviour"
        • dwheeler 5y ago
          They did do that. It's "command -v".
      • gnubison 5y ago
        That’s not usually how standards are supposed to work — a POSIX operating system should not reimplement Linux, it should only have to reimplement what’s portable to existing systems.
• pxc 5y ago
  Huh. Apparently `command` is a shell builtin for POSIX shells, not a standalone program. You might still want `which` if you're running in a non-POSIX shell that doesn't implement `command`. Seems fine to deprecate its usage inside bash scripts or scripts that you know are pegged to an interpreter that implements `command`, though.
  • anonydsfsfs 5y ago
    The Debian shell's implementation of "command" isn't POSIX compliant due to the following bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874264
    • pxc 5y ago
      Also another comment on this post indicates that macOS does come with an executable in `/usr/bin/command`. I assume it does basically nothing. Maybe it's there from when the default login shell was `tcsh`, since tcsh doesn't include a `command` builtin. In that case, it would provide the same functionality as long as no one defines a tcsh function or alias called `command`.
• unethical_ban 5y ago
  >"surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job" I'm immediately turned off by this person. They don't say exactly who or when the command was altered to put the warning in place, but it sounds like one inept, opinionated person decided to flip a switch without caring about any other practical reasons that conflict with his puritan take.
  • __turbobrew__ 5y ago
    I have never heard about ‘command -v’ before this article. Guess I’m just incompetent.
• mise_en_place 5y ago
  I actually disagree that they shouldn't allow alternatives for `which`. IMO, just provide all of them and let the user decide. I should be able to choose from GNU which, BSD which, busybox which, or an alias to `command -v`. Default just keep it as GNU which.
  • xg15 5y ago
    In that case, have fun finding out which particular version is needed by the next install script you want to run.
• jagger27 5y ago
  Here's how zsh 5.8 behaves on macOS: $ which {which,type,command,vi} which: shell built-in command type: shell built-in command command: shell built-in command /usr/bin/vi $ type {which,type,command,vi} which is a shell builtin type is a shell builtin command is a shell builtin vi is /usr/bin/vi $ command -v {which,type,command,vi} which type command /usr/bin/vi Which is quite different from how bash 5.1 behaves: bash-5.1$ which {which,type,command,vi} /usr/bin/which /usr/bin/type /usr/bin/command /usr/bin/vi bash-5.1$ type {which,type,command,vi} which is hashed (/usr/bin/which) type is a shell builtin command is a shell builtin vi is /usr/bin/vi bash-5.1$ command -v {which,type,command,vi} /usr/bin/which type command /usr/bin/vi I wouldn't want to be the one responsible for making this change, that's for sure. command -v does seem like the most reasonable choice in both circumstances, though. /usr/bin/type and /usr/bin/command are indeed just the same shell scripts. file /usr/bin/{which,type,command} /usr/bin/which: Mach-O universal binary [...] /usr/bin/type: POSIX shell script text executable, ASCII text /usr/bin/command: POSIX shell script text executable, ASCII text cat /usr/bin/command #!/bin/sh # $FreeBSD: src/usr.bin/alias/generic.sh,v 1.2 2005/10/24 22:32:19 cperciva Exp $ # This file is in the public domain. builtin `echo ${0##*/} | tr \[:upper:] \[:lower:]` ${1+"$@"}
  • anonydsfsfs 5y ago
    "command -v" isn't reliable because several shells (including Dash) don't obey the POSIX standard. See https://github.com/oilshell/oil/blob/8fbc09bb3254cee944b0450f640e268c2f627bec/spec/builtins2.test.sh#L78 https://github.com/oilshell/oil/blob/8fbc09bb3254cee944b0450...
    • lucb1e 5y ago
      I checked your link but I don't quite get it. Is status=0 supposed to be a check rather than an assignment? Either way, it doesn't have that behavior like that for me on Debian: it behaves the same as bash. This is in dash: $ command -v whoami /usr/bin/whoami $ echo $? 0 $ command -v echo echo $ echo $? 0 $ command -v nonexistent $ echo $? 127 So that is with both a proper command (whoami), a shell built-in (echo), and neither (nonexistent). It's all as I would expect from a shell. Bash does exactly the same, although dash chooses 127 as exit status and bash chooses 1 but they're both nonzero (thus error statuses).
• AceJohnny2 5y ago
  I gotta believe Mr Corbet's impetus for writing this story was for the season-appropriate pun. But as always, he still produced an insightful story on important Linux infrastructure.
• deleted 5y ago
  [deleted]
• dekhn 5y ago
  I use 'type' because many commands end up being aliases or bash functions :(
• donatj 5y ago
  The base Debian docker images don't come with `ps` either, which caused me a world of hurt earlier this year.
• overgard 5y ago
  When I read stuff like this I can't help but wonder how anything ever even gets done on this project. The amazing thing is 'which' was working perfectly fine for everyone. Just leave it alone? The amount of time they wasted on debating this is staggering compared to just not changing it.
  • Liquix 5y ago
    >I can't help but wonder how anything ever even gets done on this project Slowly, methodically, and with minimal user impact. As mentioned at the end of the article, what first appears a waste of time for a small issue could also be seen as a beautiful illustration of the democratic process that makes Debian so stable/widely adopted.
    • dangerface 5y ago
      > Slowly, methodically, and with minimal user impact. I am confused. Isn't the article about an individual just randomly deciding to deprecate which and the resulting fallout that impacted all of Debians users?
    • overgard 5y ago
      And yet they destabilized things by adding the deprecation/trying to get rid of it. And what even was the point of that?
      • Rygian 5y ago
        They<the package maintainer> ≠ They<the committee>
      • 2muchcoffeeman 5y ago
        They also mentioned how this could happen at the end of the article. In the end they are working on a distro with certain ideals and this illustrates how they can achieve things with their ideals in mind.
        • deleted 5y ago
• binkHN 5y ago
  I can appreciate this. I've seen similar things come up in the OpenBSD community. A lot of thought is given, but often times a decision is made fairly judiciously by the benevolent dictator, Theo.
• a0-prw 5y ago
  I've used Debian since (I think) from late 00s and Linux from 98. Didn't even know what Which does. Maybe I forgot ;)
• OliverJones 5y ago
  By this logic, we'd also rename awk to something more "meaninful" because the names of Aho, Kernighan, and Weinberger are just historical artifacts. They are indeed, but we're talking about a real-world "we all talk UNIX" language here that's been around for a long time -- perilously close to 2.14 billion seconds in fact. Lots of people and programs speak, read, and write this UNIX language. It's creeping up on natural human language status. This "which' is a vocabulary word of that language. Heavily used languages evolve. And you know what? They never evolve healthily when they ban the use of "obsolete" vocabulary. Languages embody history. Even PowerShell! This language won't benefit from an Académie Française - style iron-fisted rule.
  • earthscienceman 5y ago
    Neither does French, but it doesn't stop them...
• darkwater 5y ago
  My memory might be tricking me but I learnt about 'which' on a late '80s HP9000 running HP-UX, using bourne shell and it's output was the same as GNU which. But I might be swapping memories with early Linux.
• dwheeler 5y ago
  A great thing about the POSIX standard is that it's publicly available. See: https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/ https://pubs.opengroup.org/onlinepubs/9699919799.2018edition... You can see more about "command" here: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c...
• kbenson 5y ago
  Regardless of whether 'command -v' is a better alternative, 'which' is ensconced as standard practice in many shell scripts, and I would go so far as to say I think the majority of them that actually have to choose between the two use 'which'. Given that, having it print out a deprecation warning without considering what that means to all the people that use it is irresponsible. I help manage a few hundred servers. We send root email to a list and actually review it all every day. We make sure to sanitize anything run from cron so that we only get email output on error (STDERR). Given that some of those cron jobs run quite often, this would have been thousands of emails to sift through if we used Debian. There were many possible solutions, as the maintainer notes. Unfortunately in trying to remove themself from the decision, they forced a non-solution on everyone that is disruptive. I can't think of any way this is a good choice for this particular set of facts (I can see a deprecation warning being warranted for some other things, but this case has little to do factually with those theoretical situations).
  • lucb1e 5y ago
    > having it print out a deprecation warning without considering what that means to all the people that use it Virtually every command can fail in some way, and they will all write to stderr (or worse, stdout, but that's not what happened here). How is that unexpected at all? How else would you communicate the change? (For the sake of argument, let's say the change is going to happen regardless, since you're arguing for the irresponsibleness of showing a warning.)
  • deleted 5y ago
    [deleted]
  • inkyoto 5y ago
    > 'which' is ensconced as standard practice in many shell scripts Ugh. Now that the UNIX universe has collapsed unto Linux, BSD's and very, very few other *X's, it is less of an issue, but «which», due to it having never been enshrined in standards, has never been safe to use in shell scripts, and an invocation could yield a suprise for the unprepared. At least on Solaris (if I am not mistaken), the «which» output yields *two* lines, of which the first is useless (along the lines of «ohiyo, lookie at what I have found») and with the second being the actual path to the binary. So «which» has never been truly portable and safe to use.
• sigzero 5y ago
  The only think I don't like about command -v is that it will output the alias if one is set. That is 100% of the time what I do not want.
• gorgoiler 5y ago
  SunOS’s which always returned 0, no matter what. Good times that, thanks for the memory, ahem.
• mikl 5y ago
  `which` is an extremely commonly used command, has an intuitive name, is a very small program. Removing it from the standard distribution would be a huge annoyance to everyone who uses it. One more package you have to remember to install on every system to be productive.
  • lucb1e 5y ago
    > One more package you have to remember to install on every system to be productive. Everyone has different preferences though, e.g. for me vim is an essential package. That's why I have a few functions in my bashrc that installs packages in different environments. Here are some of them, with a representative excerpt of the packages: - function defaultinstall { apt install curl sudo vim ping etc. } - function defaultinstall_laptop { apt install lshw powertop gnome-power-manager etc. } - function defaultinstall_wifi { apt install wavemon iw etc. - function defaultinstall_android { apt install sqlite3 etc. } - function defaultinstall_optional with various languages like php and ruby, a mariadb client, cloc, gifsicle, iperf3, apt-file and it then runs apt-file update, etc. Before having these functions, I noticed that I'd often be missing packages (sometimes while offline). If you really want `which`, you can install the variant you want. I would do the same (because, interactively, I find `which` easier to type, even if I use the portable `command -v` in scripts).
• shmerl 5y ago
  Never heard of command, thanks for pointing it out! Try this: command -V command command -V which
• kelnos 5y ago
  > * The POSIX-blessed way of finding an executable program is command -v, which is consequently built into most shells. Given the standard alternative, Adams said, "surely no one competent would choose to have a package depend on `which` when a standard POSIX utility can do a better job".* This feels a little tone-deaf to me. I've been using the *nix command-line and writing (and reading) shell scripts for 20+ years, and I'd never heard of "command -v" until now. Now that I know about it, I'll probably start trying to retrain my muscle memory to use it (though it requires 2x the number of keystrokes). Despite its lack of true standardization, "which" (along with "type -p") has been the de-facto "standard" I've seen in shell scripts for figuring out if a command exists. It was a surprise to me to learn that "which" isn't a part of POSIX, even.
  • liquidise 5y ago
    My story would echo this same sentiment. Incidentally, running `man command` on OS X actually does not reference a '-v' option at all, instead only stating the more verbose `command which`. Both appear to work, but it further highlights your (our) discoverability issue(s).
    • createunderrate 5y ago
      `command which` just executes `which`
    • Izkata 5y ago
      There is no man or info page for "command" on Ubuntu, I guess it's just a bash builtin ("which command" doesn't find it). "which" has a man page though.
      • rascul 5y ago
        For bash, it is documented with 'help command' or the bash man page, section SHELL BUILTIN COMMANDS.
      • sevensor 5y ago
        In bash, such things are documented in the help system: $ help command command: command [-pVv] command [arg ...] Execute a simple command or display information about commands. Runs COMMAND with ARGS suppressing shell function lookup, or display information about the specified COMMANDs. Can be used to invoke commands on disk when a function with the same name exists. Options: -p use a default value for PATH that is guaranteed to find all of the standard utilities -v print a description of COMMAND similar to the `type' builtin -V print a more verbose description of each COMMAND Exit Status: Returns exit status of COMMAND, or failure if COMMAND is not found.
• 0xbadcafebee 5y ago
  Distributions that ship their own distro-specific custom version of an already popular tool need to have their heads examined.
• dec0dedab0de 5y ago
  I'm still mad at whoever removed screen from redhat.
• throwaway09223 5y ago
  There's a problem with "command -v," in that it's not actually a command. It's a Bourne shell builtin. You can't use `command -v` in csh or other shells, only in Bourne style shells (bash, zsh, etc). /usr/bin/which is a standalone binary. It can be invoked without a shell at all. Many comments discussing `command` being part of POSIX are I think missing that `command` is only part of POSIX insofar as the Bourne shell is defined by POSIX. It is part of a POSIX `/bin/sh` and is not its own thing. Keeping /usr/bin/which is the correct decision and it should probably be added to POSIX.
  • 22c 5y ago
    You can use command -v in any POSIX compliant shell. csh is not POSIX compliant. Your list of shells in inexhaustive to the point of being almost misleading. bash and zsh are "heavy-weight" shells, a lot of lightweight shells also support command. If you're specifying your shebang as #!/bin/sh then you should not assume you have access to functions like type or binaries like which, but you can generally assume you have access to the command built-in.
    • throwaway09223 5y ago
      Well the point is that it's a shell component, so it's not available from anything other than a shell which is undesirable. I understand Bourne style (POSIX) shells have the vast majority of the market, but the point is breaking other environments. "command -v" is not available everywhere so it is not a viable replacement for /usr/bin/which.
      • 22c 5y ago
        "which" is also not available everywhere, that's how I know about "command -v".
    • rascul 5y ago
      > If you're specifying your shebang as #!/bin/sh then you should not assume you have access to functions like type 'type' is actually POSIX though. bash does extend it. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html https://pubs.opengroup.org/onlinepubs/9699919799/utilities/t...
• Pxtl 5y ago
  Going from being the recommended way to do something into being deprecated in under 2 years is such hard deprecation whiplash they're going to make Google jealous.
• _kst_ 5y ago
  Without commenting on what Debian should do about this, I've pretty much given up using `which` myself. Since `which` is an external command (it's built into some shells, but not bash), it doesn't know about aliases, shell functions, or builtin shell commands. I've found that bash's built-in `type` command (with its various options) does whatever `which` does, and often does it better. I also use `command -v foo >/dev/null` to detect whether the command `foo` exists -- for example: if command -v less >/dev/null ; then export PAGER=less fi I suppose I could also use `type` for the same purpose. It would be nice if `type` and/or `command` had an option to check whether a command exists without printing anything, but having to add `>/dev/null` is only a minor annoyance.
• cryptonector 5y ago
  Removing `which(1)` -- them's fightin' words right there.
• asicsp 5y ago
  Reminds me of this famous Q&A "Why not use "which"? What to use then?" - https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then https://unix.stackexchange.com/questions/85249/why-not-use-w...
• billpg 5y ago
  I remember writing scripts with $(which something) in the past. I cannot remember why I needed that.