SC2230 - command -v is not a direct replacement for which

[arth1]

For bugs

• Rule Id (if any, e.g. SC1000): SC2230
• My shellcheck version (shellcheck --version or "online"): 4.4.7 (latest from git)
• I tried on shellcheck.net and verified that this is still a problem on the latest commit

Here's a snippet or screenshot that shows the problem:

#!/bin/sh

which "$0"
/usr/bin/which "$0"
command -v "$0"

Here's what shellcheck currently says:

In test.sh line 3:
which "$0"
^-- SC2230: which is non-standard. Use builtin 'command -v' instead.

In test.sh line 4:
/usr/bin/which "$0"
^-- SC2230: which is non-standard. Use builtin 'command -v' instead.

Here's what I wanted or expected to see:

Because "command -v" does not do the same as which, I would have liked to see nothing.
When running the above (from /tmp), I get:
/tmp/test.sh
/tmp/test.sh
./test.sh

While "which" may not be standard, it is commonly used to get the full path.
At the very least I would like to not get warned when I specifically use the path as in the third command - then it's fairly certain what the user wants, which won't be the common bash alias.

[Dmole]

You could use 'pwd'.

'which' is not posix
http://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html
and not gnucore
https://en.m.wikipedia.org/wiki/List_of_GNU_Core_Utilities_commands

but it sure seems common to me.. where is it not?
also shellcheck is not warning about far less common things like Java... seems like a false positive to me.

[brodygov]

command -v also has slightly different behavior since it will return success for shell built-ins and functions that do not exist as standalone commands, whereas which only searches the PATH.

For example:

$ which if
# exits nonzero

$ command -v if
if
# exits zero

$ foo() { true ; }
$ which foo
# exits nonzero
$ command -v foo
foo
# exits zero

[pedroarthur]

Besides that, which a b c exits zero if all of a, b, and c exist. Meanwhile, command -v a b c exits zero if any of a, b, or c exists.

[pdietl]

So do we think that this check should be removed?

[brodygov]

👍 I would favor removal.

[Light-Wizzard]

which can be replaced with type -p,
but it still needs the -x, I do not get any warnings using this:
[[ -x "$(type -p dir 2>/dev/null)" ]]

[leagris]

An alternative to which command, when you need to know the path of a non built-in command:

type -P ls
/bin/ls

[oliv3r]

While which can certainly be used if a user decides to (they can easily ignore the shellcheck warning, the argument 'but it is so common and always available' is of course moot and opinionated (yes, even busybox features it these days).

The point remains, if you use /bin/sh you kind of imply POSIX compliance, and even if not, some of us would still like this warning to be triggered. Just as which not being standard (again, even with being so ever common).

As with everything, there are exceptions of course. But I think this is not one of them, the exception should be in your code or your parser, where you globally or locally ignore this test as that would work for you. (You being not the individual personal you).

A fair improvement of course would be to the wikipage, for users who run into this, get noted of this.

While surely there are a few valid usecases, I was thinking a bit more about this, and from a users point of view, I can imagine the difference "will this command work in my script (command -v) vs what is the path of this utility (which)". Sometimes a user may be interested only where the binary is, rather then whether it will work. My earlier thoughts still remain the same, but the wiki surly needs clarification of this exceptional case.

Not sure of the complexity, but shellcheck could of course try to figure out the intend. Is the result stored in a variable and that variable only passed along/used as a string, or invoked as a program, it should be a valid use case? Detecting the other uses however is a bit harder I suspect however. but then also relate this to the 'is which being used as a standard tool' or not.

I suppose a decent workaround would be:
WHICH="$(command -v which)"
which would fail if which is not available :) and users of which can use WHICH instead :)

[pedroarthur]

This is a example where which and command diverge. Using which, I check if all the tools I need exist with a single statement. If I use, command -V, it will return 0 if any of the tools exist.

#!/bin/bash
tooling=( bash no_such_command )

# shellcheck disable=2230
which      "${tooling[@]}" &> /dev/null || echo some tools are missing
command -v "${tooling[@]}" &> /dev/null || echo some tools are missing

Hence, command -v is not a replacement for which.

[oliv3r]

is this even supposed to work?
I use it as such:

check_requirements()
{
    for cmd in ${CMDS}; do
        if ! test_result="$(command -V "${cmd}")"; then
            test_result_fail="${test_result_fail:-}${test_result}\n"
        else
            test_result_pass="${test_result_pass:-}${test_result}\n"
        fi
    done

    echo "Passed tests:"
    # As the results contain \n, we expect these to be interpreted.
    # shellcheck disable=SC2059
    printf "${test_result_pass:-none\n}"
    echo
    echo "Failed tests:"
    # shellcheck disable=SC2059
    printf "${test_result_fail:-none\n}"
    echo

    if [ -n "${test_result_fail:-}" ]; then
        echo "Self-test failed, missing dependencies."
        exit 1
    fi
}

which yes, is a lot longer, but also is a lot friendlier to the user imo :)

so yeah, which can do this in one line, but just because you can, doesn't mean you should imo :)

[pedroarthur]

is this even supposed to work?

Yes, which is supposed to work this way since day 0. Have you read its man page?

so yeah, which can do this in one line, but just because you can, doesn't mean you should imo :)

So, you advocate to maintain 15+ LoC that triggers far more concerning checks instead of a single one that just has a "non-standard tool" warning? Thank you, but no.

However, the main issue here is saying that things are interchangeable when they aren't. Following the advice in this check can break perfectly working code.

[oliv3r]

is this even supposed to work?

Yes, which is supposed to work this way since day 0. Have you read its man page?
Nope :)

so yeah, which can do this in one line, but just because you can, doesn't mean you should imo :)

So, you advocate to maintain 15+ LoC that triggers far more concerning checks instead of a single one that just has a "non-standard tool" warning? Thank you, but no.
more concerning checks? I personally prefer to have an output like:

Fair point, which does the same in one go, which is indeed (no pun intended) admittedly quite nice. So at the least, the wording could be improved absolutely. But the fact remains, and the warning, that it is a non-standard tool. So a green warning should be sufficient.

However, the main issue here is saying that things are interchangeable when they aren't. Following the advice in this check can break perfectly working code.

nod

[HalisCz]

I've found out another difference between which and command -v:

$ alias ls
alias ls='ls -al'
$ which ls
/usr/bin/ls
$ command -v ls
alias ls='ls -al'
$ type -P ls
/usr/bin/ls

Therefore I think the suggestion should be replace which with type -P.