How to analyze this command `{ 2>&3 "$@"& } 3>&2 2>/dev/null`?

Question

A few weeks ago, I have seen a weird answer about the question "(How to) silently start task(s) in the background?". This solution seems incorrect (c.f. my answer) although the shell seems to start the task silently in the background.

I. Issue: can we actually redirect the shell standard error?

There is no explanation with the proposed solution and an analyze does not provide a reliable answer.

Below, you can see the code snippet.

# Run the command given by "$@" in the background
silent_background() {
   if [[ -n $BASH_VERSION ]]; then
      { 2>&3 "$@"& } 3>&2 2>/dev/null
   fi
}

The problematic command is { 2>&3 "$@"& } 3>&2 2>/dev/null.

i) Analyze

The group of commands ({ ... }) specifies two redirections (3>&2 and 2>/dev/null) for one command (# Run the command given by "$@" in the background). The command is an asynchronous list (cmd&) having one redirection (2>&3).

POSIX specification

Each redirection shall apply to all the commands within the compound command that do not explicitly override that redirection.

The standard error redirection 2>/dev/null is overridden by the redirection associated to the asynchronous list 2>&3.

Concrete cases

In the first case, the standard error is redirected to /dev/null whereas, in the second case, the standard error of the command is still attached to the terminal.

prompt% { grep warning system.log& } 2>/dev/null
prompt% { 2>&3 grep warning system.log& } 3>&2 2>/dev/null
grep: system.log: No such file or directory

Below, we can see similar cases. In the first case, the standard output of the command is still attached to the terminal. In the second case, the standard output redirection of the command is modified: >echo.txt is overridden by >print.txt.

prompt% { >&3 echo some data...& } 3>&1 >echo.txt
[1] 3842
some data...
prompt% file echo.txt
echo.txt: empty
prompt% { >&3 echo some data...& } 3>print.txt >echo.txt
[1] 2765
prompt% file echo.txt
echo.txt: empty
prompt% cat print.txt
some data...

ii) Observations

As previously mentioned, the command seems to start silently in the background. More precisely, the notification about a background job, e.g. [1] 3842, is not displayed.

The previous analysis implies that the redirects are superfluous since they may be canceled.

{ redir_3 cmd& } redir_1 redir_2 is equivalent to cmd&.

iii) Interpretation

In my mind, the mentioned construct hides the notification because of a side effect.

Can you explain how that happens?

II. Hypothese(s)

Ilkkachu's answer and comments allowed some progression. Note that each process has its own file descriptors.

• The shell messages may be send on the shell standard error.

Another context: An asynchronous list executed in a subshell. The command g does not exist.

prompt% ( g& )
g: command not found

Asynchronous commands, commands grouped with parentheses,..., are executed in a subshell environment that is a duplicate of the shell environment...

A subshell inherits the value of its standard error stream from its parent shell.

Therefore, in the previous case, their standard error streams should refer to the terminal. However, the job notification is not displayed whereas the shell error message is probably displayed on the shell standard error.

Answer 1

You missed the most important point, shell redirection is applied in order from left to right.

In:

{ 2>&3 "$@"& } 3>&2 2>/dev/null

The whole group command is run with:

• File descriptor 3 => standard error, which is terminal at this time.
• File descriptor 2 (Standard error) => /dev/null

So when command inside grouping run:

• Standard error => File descriptor 3, which is pointed to terminal.

So if "$@"& print anything to its standard error, the output is printed to terminal.

---

For your concrete cases:

{ grep warning system.log& } 2>/dev/null

{ grep warning system.log& } runs with standard error is pointed to /dev/null. grep does not override any redirection so its standard error is the same with {...}, and is redirected to /dev/null, you got no output to terminal.

In:

{ 2>&3 grep warning system.log& } 3>&2 2>/dev/null

grep's standard error is redirected to file descriptor 3, which is pointed to terminal as explained above, so you got output to terminal.

Answer 2

In interactive Bash, foo & runs foo in the background, and prints its job id and process id to the shell's standard error.

foo 2>/dev/null & runs foo in the background, with its stderr redirected to /dev/null, but still prints the job id and process id to the shell's standard error (not the redirected stderr of foo).

{ foo & } 2>/dev/null first redirects stderr to /dev/null, then the inside of the {} is processed with that redirection applied. Then foo is started in the background, and the job id and process id printed to the now redirected stderr of the shell (i.e. to /dev/null).

Bash's manual implies that the redirections outside the group apply to the group as a whole:

When commands are grouped, redirections may be applied to the entire command list.

We can verify the redirection applied the group also redirects the job id output:

$ { sleep 9 & } 2> temp
[ no output here ]
$ cat temp
[1] 8490

When the command eventually exits, the notice from that does appear on the terminal, however: (Or rather, to the shell's current stderr, whatever that is.)

$ kill %1
[1]+  Terminated              sleep 99

---

In { ... } 3>&2 2>/dev/null, fd 3 is redirected to where ever stderr points to now, then stderr is redirected to /dev/null. Assuming stderr originally pointed to the terminal, the result is 3 -> terminal, 2 -> /dev/null. These redirections apply to the group.

If we have { foo 2>&3 & } inside the group, foo is started in the background, with its stderr pointed to the group's fd 3, and the job id and process id are printed to the group's stderr.

Putting these two together, foo's stderr is pointed to where the group's fd 3 points to, i.e. the original stderr, and the job id is printed to the group's fd 2, i.e. /dev/null.

So, in effect, { 2>&3 foo & } 3>&2 2>/dev/null redirects the job id and process id printed by the shell to /dev/null, and routes foo's stderr around this redirection:

foo's stdout      -> group's fd 1 -> original stdout (never redirected)
foo's stderr      -> group's fd 3 -> original stderr
job id from group -> group's fd 2 -> /dev/null

Answer 3

You're missing that the { command runs with a nulled stderr, it starts the contained background commands with the restored fd, but it's the one starting the commands and issuing the command-started feedback messages, and it runs with the nulled one.