Re: BUG: Shell builtin `which` prints non-existent commands to stdout

[Stephane Chazelas <stephane.chazelas@xxxxxxxxx>]

2018-09-24 13:51:24 +0100, Peter Stephenson:
> On Mon, 24 Sep 2018 14:29:33 +0200
[...]
> +  The issue is that if you run:
> +  verb(
> +    which non-existent-command
> +  )
> +  the error message goes, unusually, to standard output rather than
> +  to standard error.  Other shells send this message to standard error,
> +  as they would if the command was about to be executed but could not be
> +  found.
[...]

About "other shells" above, AFAIK, tcsh is the only other shell
that has a "which" builtin and it does also send "command not
found" to stdout. So zsh behaves like every other shells in that
regard.

To phrase my last comment differently, there are also a variety
of "which" command implementations outside of any shell, the
first of which (which appeared in 3BSD) was primarily intended
for csh users (as it read your ~/.cshrc for aliases) and was
written as a csh script that did also send the "command not
found" to stdout.

That's also the one still found on many commercial Unices.

There is also a GNU "which" command (which tries to generalise
what that csh script did for other shells) and sends the
command-not-found to stderr.

Debian has a POSIX sh which script that doesn't output any
command-not-found error and doesn't look-up aliases of any
shell (it writes the usage message on stdout followed by the
"illegal option" on stderr).

BSDs which has now been merged with whereis and been rewritten in
C and no longer looks up your csh aliases and like the Debian
script doesn't output any command-not-found error.

See also
https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then

-- 
Stephane