^ /dev/null redirection doesn't work on some error messages

[tannhuber]

I'm astonished why the following commands produce output:

-> unknown_command > /dev/null ^ /dev/null
fish: Unknown command 'unknown_command'

-> .. foo > /dev/null ^ /dev/null
The file '..' is not executable by this user 

Is it possible to suppress these error message?

[iirelu]

The error message is from fish itself, not the command, so you can't pipe it elsewhere.

[tannhuber]

In zsh, bash, dash and ksh it does. And that's the behavior I would expect. From a user perspective it doesn't matter whether an error message is produced by a command or by the shell itself.

[xdudi]

function execute
        if test (count $argv) -eq 0
                return 0
        end

        if which $argv[1] > /dev/null
                eval $argv
                return $status
        else
                return 1
        end
end

execute unknown_command > /dev/null ^ /dev/null

It should resolve your problem.

[KamilaBorowska]

@xdudi: This is called workaround, and also bad one, because it's affected by race conditions.

[szhu]

@tannhuber you can fix this error by using a command you know for sure exists. How about env?

env unknown_command > /dev/null ^ /dev/null

(I know this is an old issue but it's still open so hope this helps)

[gpakosz]

Could you please make it so the following can be silenced completely?

exec /unknown/command ^>/dev/null` 

For the record, I'm insisting on using exec as it allows me to abuse how tmux names windows. Still having fish behave like other shells in that respect is a win imho.

[ridiculousfish]

I wonder how bash implements this. Does it fork just to output the error message? The recursive cases are a little funny but seem to be handled correctly:

echo hi 2> /not/a/valid/path

anyone like to check how bash implements this?

[krader1961]

Bash (and presumably zsh and ksh) does the redirection for exec in the parent shell. From execute_builtin_or_function() in execute_cmd.c:

  /* Calling the "exec" builtin changes redirections forever. */
  if (builtin == exec_builtin)
    {
      dispose_redirects (saved_undo_list);
      saved_undo_list = exec_redirection_undo_list;
      exec_redirection_undo_list = (REDIRECT *)NULL;
    }

You can see this for yourself by starting bash and doing the following

$ exec /no/such/command >/dev/null
$ echo hello

Note that one of the few sh/bash/ksh/zsh features I'd really like to see fish adopt is the ability to use exec to redirect stdout and stderr for the current shell without actually running a command; e.g., exec >/tmp/stdout.%self ^/tmp/stderr.%self. Assuming %self actually expanded when used like that. That it doesn't is a different discussion I'd like to have but is a good reason why bash, et. al., use $$ for the shell pid.

Fish forks when it doesn't need to which is the source of some of our performance problems. However, that isn't really relevant to this issue.

The main problem is how the use of the io_streams_t object interacts with the places in fish which directly write to the stdout/stderr stdio file handles (or fd 1 and 2 for low level I/O). Whether we should replace that object with something like the struct redirect used by bash or pass that object and use it everyplace we might write to stdout or stderr is TBD.

[krader1961]

@gpakosz, your example fish syntax when translated to the equivalent bash form leaves the shell essentially unusable since you'll no longer see the command prompt or the output of any commands:

bash-4.4$ exec /unknown/command >/dev/null 2>&1

At that point bash is waiting for me to type a command. However the bash prompt and the output of whatever command I type is also written to /dev/null. We most definitely do not want to allow that in an interactive fish session. Have you really been doing that in bash just to change the tmux window/pane name? If so there are less dangerous ways to do that.

[krader1961]

@tannhuber, I actually think fish's behavior is more defensible. You also wrote that

In zsh, bash, dash and ksh it does.

But it doesn't. I created this two line script:

#!/usr/local/bin/bash
/invalid/command >/dev/null ^/dev/null

When I run it I see this written to my terminal:

./b: line 2: /invalid/command: No such file or directory

The same thing happens in an interactive bash session. Sorry, but the current fish behavior is basically correct. I say "basically" because there may very well be instances where fish is writing to stdout or stderr, as I noted in a previous comment, where it should be, but does not, honor redirection. However, the two examples by @tannhuber and @gpakosz do not work the way they claim and even if they did we do not want fish to behave that way.

[gpakosz]

@krader1961 I'm not sure this is the right place to discuss my tmux hack as it's definitely off topic but I don't have a better idea.

What I'm doing is: exec /unknown/command 2>/dev/null & /valid/command

Tmux has no way to rename a pane. You can only name a window. In the following situation:

• pane1 runs command /foo
• pane2 runs command /bar

You can rename the window to baz but you can't rename only pane1 or pane2 to baz.
I have a such specific case where I want to override the name of a pane but not the name of the parent window: the enhanced maximized pane feature of my tmux conf.

I'm exploiting the fact that tmux uses the basename of the command passed to exec and ignores the remaining of the command string. Hence I'm doing exec baz... 2>/dev/null & /some/real/command.

Hope that sheds some light on "why oh why would this guy do this ffs?"

[krader1961]

@gpakosz, That does better explain what you're doing. And you're right: that is unrelated to this issue. You're exploiting a quirk of how bash handles redirections when backgrounding a job. However, when I do that in bash I get output that is little different from what fish provides:

bash-4.4$ exec jksdlf 2>/dev/null & echo hello
[1] 90819
hello
bash-4.4$
[1]+  Exit 127                exec jksdlf 2> /dev/null
bash-4.4$

Note that bash actually puts the bogus command into the background then immediately reports that it failed because it could not be found. Whereas fish does this:

fish$ exec jksdlf & echo hello
fish: Unknown command 'jksdlf'
fish: exec jksdlf & echo hello
           ^
hello

I fail to see how that is materially different from what bash did.

While I've been using tmux for approximately 10 years (and screen before that) I've never embraced tmux "panes". I limit myself to one or more tmux "windows" inside a single tmux session. So I'm not going to be of much help suggesting a more fish friendly approach.

It seems unlikely we're going to modify fish solely to interact with labeling of tmux "panes". However, if you can make an argument for why different behavior would be useful in other contexts please open a new issue and we'll be happy to consider the matter.