Bash redirection: append to a file descriptor (2>>&1)

Inside $(...), stdout (fd 1) is a pipe. At the other end of the pipe, the shell reads the output and stores it into the $result variable.

With: $({ blah; } 3>&1) we make it that both fd 3 and 1 point to that pipe in blah.

blah is cmd1 | cmd2. There cmd1 and cmd2 are started concurrently with cmd1 fd 1 pointing to another pipe (the one to cmd2), however we don't want ssh output to go to that pipe, we want it to go to the first pipe so that it can be stored in $result.

So we have { ssh >&3; echo "$?"; } | cmd2, so that only the echo output goes to the pipe to cmd2. ssh output (fd 1) goes to $result. ssh not needing a fd 3, we close it for it after we've used it to set fd 1 (3>&-).

cmd2's input (fd 0) is the second pipe. Nothing is writing to that pipe (since ssh is writing to the first pipe) until ssh terminates and echo outputs the exit status there.

So in cmd2 (being the until loop), the read -t1 is actually waiting with timeout until ssh exits. After which, read will return successfully with the content of $? fed by echo.

Redirections are implemented via the dup family of system functions. dup is short for duplication and when you do e.g.:

3>&2

you duplicate (dup2 ) filedescritor 2 onto filedescriptor 3, possibly closing filedescriptor 3 if it's already open (which won't do a thing to your parent process, because this happens in a forked off child (if it does not (redirections on shell functions in certain contexts), the shell will make it look as if it did)).

When you do:

1<someFile

it'll open someFile on a new file descriptor (that's what the open syscall normally does) and then it'll dup2 that filedescriptor onto 1.

What the manual says is that if one of the special dev files listed takes the place of someFile, the shell will skip the open-on-a-new-fd step and instead go directly to dup2ing the matching filedescriptor (i.e., 1 for /dev/stdout, etc.) onto the target (filedescriptor on the left side of the redirection).