Sadly, much of this article is an example of why you shouldn't learn from other people's shell scripts. Too often shell scripts are quickly written without much attention to best practices, so they have a lot of bad habits in them. For much the same reason bad code tends to get copy and pasted about until it becomes common such common practice no one questions it.

One shouldn't use which at all. It forks an external process, it is vulnerable to PATH issues unless you specify what will surely be a non-portable path to the executable, often isn't included in chroot'd environments, and doesn't actually return an exit status on many platforms. In short: it sucks in almost all possible ways you could hope to suck.

The proper expression to use is:

    command -v curl >/dev/null 2>&1

If you know you are in bash, type -P and possibly hash become acceptable alternatives, but then... why not just use command -v right?

One "moment of clarity" I had is to realise that 2>&1 is a RIGHT-TO-LEFT assignment - file descriptor 1 gets assigned to file descriptor 2.

This is why (to redirect both stdout and stderr to $file) you have to do e.g. 1>$file 2>&1 rather than the more obvious-looking 2>&1 1>$file.

`2>&1 > /dev/null` will drop stdout and write stderr to stdout.

`> /dev/null 2>&1` will drop both stdout and stderr.

For myself, with `which` I would just use `> /dev/null`, as `which` writes to stdout and not stderr: if anything comes through stderr, you probably want to know about it.

If you're using Bash, you can use this shorthand: which curl >& /dev/null