makefiles: Sort >/dev/null and 2>&1

[chrysn]

Contribution description

Redirecting 2>&1 >/dev/null moves stderr to stdout first and then
stdout to /dev/null; when checking for command existence or otherwise
silencing output, this is usually not desired (but only starts producing
errors when the actual command fails, which is often not tested).

In particular cases, the redirect made things even worse: while stderr would have gone to the user's screen otherwise, the 2>&1 >/dev/null means that warnings raised now get mingled in the later echo $? and thus make the equality check for 0 fail -- tools are then not detected any more.

Testing procedure

Try building anything on a recent Debian sid system; it will fail before with

.../Makefile.include:340: *** Neither wget nor curl is installed!.  Stop.

and now run through.

Issues/PRs references

debianutils' which, in its changelog, states:

  * The 'which' utility will be removed in the future.  Shell scripts
    often use it to check whether a command is available.  A more
    standard way to do this is with 'command -v'; for example:
      if command -v update-icon-caches >/dev/null; then
        update-icon-caches /usr/share/icons/...
      fi
    '2>/dev/null' is unnecessary when using 'command': POSIX says "no
    output shall be written" if the command isn't found.  It's also
    unnecessary for the debianutils version of 'which', and hides the
    deprecation warning.

Note that this PR does not change which to command, it just fixes the fallout of ill-sequenced redirects. That change is probably good to do, but right now this should be minimal enough to get merged quickly, and I don't want it held up in the question of whether everyone and their dog already implement POSIX command.

[chrysn]

I've set this to skip the compile tests, based on this only affecting tool detection lines; reviewers please remove that flag if you disagree.

[fjmolinas]

'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

Might this be an issue for other versions onf which then? Why not replace by command -v right away?

[fjmolinas]

Regarding testing, the behaviour is still the same but I'm using the debianutils version of which...

[chrysn]

I held off on replacing with command because that might spark discussion on whether that's really universally available.

Having found it used in the makefiles since, I'm putting the later changes on top of this.

[benpicco]

Is it even necessary to redirect stderr to stdout at this point? It will be printed either way.

[chrysn]

I was trying for minimal changes here; as that's apparently not called for (cf. #16775 (comment)), the latest additions do away with this.

[chrysn]

Regarding testing, the behaviour is still the same but I'm using the debianutils version of which...

As in "it still fails" or in "it didn't fail before"? Which command were you testing with? (My current go-to is BOARD=microbit-v2 make -C examples/saul all flash term)

[chrysn]

Seems my worries were warranted -- one of the build environments doesn't even know command.

No clue why (the python-tests job of .github/workflows/tools-test.yml is supposed to be run on ubuntu-latest whose shells do know command), but I'll revert this to only being the first commit which is minimally fixing things, and see to the rest in a follow-up.

[fjmolinas]

ACK, small enough change. Locally behaviour is the same.