build: Replace `which` command with `command -v` #24156

On some systems the which command can emit messages into stderr. For example, for debianutils 5.5-1 package in Debian Sid:

# which cat  
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
/bin/cat

Although such messages are harmless, they could distract developers needlessly (see bitcoin/bitcoin#24056).

Fixes bitcoin/bitcoin#24056.

Can't we switch to using command -v instead? Or there are platforms where which is available but shell does not have command built-in?

Can't we switch to using command -v instead? Or there are platforms where which is available but shell does not have command built-in?

#24056 (comment)

Thanks for checking about command -v avoiding a next round of hassle.

Tested ACK https://github.com/bitcoin/bitcoin/pull/24156/commits/1c45a9a900f35cf400392f926af0e08ae42d709f (tested that the message didn't appear, will do a full GUIX build to make sure the windows build works)

ACK 1c45a9a900f35cf400392f926af0e08ae42d709f

The main problem this is fixing isn't

/usr/bin/which: this version of `which' is deprecated;

it's the output from #24056 which was caused by #22093.

I mentioned here, we already use command -v, so I'm not sure why we can't use it in this case.

fanquake wrote:

I mentioned here, we already use command -v, so I'm not sure why we can't use it in this case.

hebasto [wrote][0]:

Will add some more tests and then submit a pr.

I understand you can [use command -v] and is coming in a different PR.

[0]: #24056 (comment)

@fanquake

The main problem this is fixing isn't

/usr/bin/which: this version of `which' is deprecated;

it's the output from #24056 which was caused by #22093.

Both output from #24056 and another example in the OP are generally the same -- the stderr output.

I mentioned here, we already use command -v, so I'm not sure why we can't use it in this case.

grepping gives the only place: https://github.com/bitcoin/bitcoin/blob/bd482b3ffebc68130f8a18dabf08ed1aff7ea159/depends/hosts/darwin.mk#L28-L36

and comment added in 880660acfa547558f6ef5adff6768de95e53af6e by @dongcarl (#19683) seems say the same as #24056 (comment).

Doesn't #24131 resolve this without the ugly stderr loss? (Would be bad to silence an actually-relevant warning/error in the future..)

Doesn't #24131 resolve this without the ugly stderr loss? (Would be bad to silence an actually-relevant warning/error in the future..)

I don't think it does, because on older system you still will not have the ...-g++-posix binary.

Updated 1c45a9a900f35cf400392f926af0e08ae42d709f -> 148b33cf72033eced8a701d127e21dfe8a816ce3 (pr24156.01 -> pr24156.02).

Addressed:

• @fanquake's comment
• @luke-jr's comment

Code Review ACK 148b33cf72033eced8a701d127e21dfe8a816ce3

Somewhat frustrating upstream bug, but it is what it is 🤷

Code review ACK 148b33cf72033eced8a701d127e21dfe8a816ce3

I don't think it does, because on older system you still will not have the ...-g++-posix binary.

True. But the problem here isn't so much older systems. It's that when doing a guix build, depends is used to download the packages. This is done outside the build sandbox (because no network connectivity is available there). There, no C++ compiler needs to be installed at all, let alone a mingw one.

<!--9cd9c72976c961c55c7acef8f6ba82cd-->

Guix builds