"Unknown command" error is not redirected

[marckhouzam]

I'm resurrecting an old issue because I believe it might have been mis-diagnosed (see below). My apologies if I mis-understood the description and answers of #1674 (blocked for comments).

I'm working on adding Fish auto-completion to the Cobra golang project on which kubectl, helm and many other tools are based.

I've run into this problem, where stderr redirection does not work for error messages printed by Fish itself.

$ invalid 2> /dev/null
fish: Unknown command: invalid
$ invalid &> /dev/null
fish: Unknown command: invalid

This was already discussed in #1674 (blocked for comments), but I humbly believe there was a mis-understanding when it was stated that other shells don't do this either. The below shows that the redirection does work for both bash and zsh. (The mis-diagnosis of #1674 (comment) came from the use of ^/dev/null which is not valid in other shells).

$ bash
$ invalid
bash: invalid: command not found
$ invalid &> /dev/null
$
$ zsh
$ invalid
zsh: command not found: invalid
$ invalid &> /dev/null
$

As stated in #1674 (comment)
"From a user perspective it doesn't matter whether an error message is produced by a command or by the shell itself."

Information:

$ fish --version
fish, version 3.1.0
$ echo $version
3.1.0
$ uname
Darwin
$ echo $TERM
xterm-256color

The problem still happens without third-party customizations.

[faho]

Typically you'd check for the command before using it -

if type -q thing

or similar.

Is there any reason you can't do that?

[marckhouzam]

Typically you'd check for the command before using it -

if type -q thing

or similar.

Is there any reason you can't do that?

Thanks! I'll give it a try. I had thought about using which but it's not always installed. Your way seems safe.

[marckhouzam]

type -q does work for me. Thank you @faho.

I personally think the larger issue remains, especially in comparaison to other shells, but if the maintainers are comfortable with the current behaviour, feel free to close this issue.

[faho]

We have some other messages that we also don't send through stderr. For the most part, these are syntax errors. E.g. something like echo (foo will complain because that's an invalid commandline, and so we can't do anything.

But having a missing command isn't really all that different - when the command doesn't exist, we also can't do anything.

Or rather we shouldn't, and we don't.

Compare

echo (nonexistent) haha

with

echo $(nonexistent) haha

The latter prints a command-not-found error and "haha" in bash, dash and zsh.

Personally, I think that's awful and not something to be imitated.

When you don't check that a command exists before, you should get an error if it doesn't, and that error should not be ignored along with all other errors that command may print.

There is a wider idea here to be had about allowing a more targeted suppression of these errors (adding some way to mark a commandline as "optional" or something?) but after thinking about it for a bit it doesn't really seem to be worth it.

Note that type -q is only part of the story: it will return true if the argument is any kind of executable thing, command -q will return true if it is an external command, functions -q (note the "s" at the end) if it is a function and builtin -q if it is a builtin. When in doubt, you should use type -q.