Como (internamente) fd3>&fd1 após { fd1>&fd3 } coloca de volta (ou não) o fd original em fd1? ("descritor de arquivo inválido")

Então, simplificando um pouco, você tem

{ a 2>&1 1>&3 | b; } 3>&1

Agora, os redirecionamentos fora do grupo de chaves precisam ser tratados separadamente dos de dentro; eles precisam ser definidos antes que qualquer coisa no grupo de colchetes seja executada. Assim, o grupo de colchetes vê os fds 1 e 3 apontando para o mesmo lugar (a saída padrão original).

Em seguida, o pipe redireciona o stdout do lado esquerdo para o stdin do processo do lado direito. Isso também acontece antes da execução de qualquer um dos lados, ou de seus redirecionamentos.

Vamos reescrever isso com a sintaxe de substituição de processo, apenas para mostrar os redirecionamentos em ordem da esquerda para a direita. _{( >(b)executa b, disponibiliza seu stdin como um nome de arquivo e expande para esse nome. Então 1> >(b)redireciona o stdout para esse "arquivo" e bo stdin de .)}

{ a 1> >(b) 2>&1 1>&3; } 3>&1

ou mesmo,

a 3>&1 1> >(b) 2>&1 1>&3

Então, aprimeiro o stdout(1) original é copiado para o fd 3 (o redirecionamento que estava fora do grupo de chaves).

Em seguida, bé iniciado, com ao stdout(1) do redirecionado para bo stdin do . aO stderr(2) do é redirecionado para o mesmo. Agora, os fds 1 e 2 vão para b, e o fd 3 vai para o stdout original.

E, finalmente, ao stdout(1) de é redirecionado para onde o fd 3 vai, que é uma cópia do stdout original, desfazendo o redirecionamento anterior do stdout para b. Agora, o fd 1 vai para o stdout original novamente, enquanto o fd 2 vai para b. Como mencionado em outra resposta , agora você também pode fechar o fd 3 com , 3>&-já que ele não é mais necessário.

Escrito dessa forma, alguém poderia perguntar se faz algum sentido, por que não fazer isso:

a 2> >(b)

E você poderia, mas a sintaxe do pipe não permite especificar qual fd ou fds redirecionar para o pipe, é sempre apenas stdout. E a substituição de processos não é um recurso POSIX, então nem todos os shells a suportam, e há o recurso irritante de que processos iniciados a partir da substituição de processos podem ser deixados em execução em segundo plano enquanto o shell principal continua, ao contrário dos pipes, onde o shell aguarda por todas as partes de um pipeline.

O 1>&2que estava lá também "desfaz" o 2>&1fato de que quando o stderr de afoi redirecionado para o pipe, o stdout do pipe (todo o grupo de chaves) é redirecionado de volta para o stderr do script.

Acho que você está confuso porque a maioria das descrições de duplicações de descritores de arquivo são meio vagas e é fácil perder os detalhes essenciais para entender isso.

5>/path/to/file

Quando um processo abre um descritor de arquivo em um arquivo, um canal de entrada/saída é formado entre o processo e o arquivo (isso também se aplica quando o objeto aberto é um diretório, um fluxo, um arquivo de rede, etc.). Você pode imaginar isso como um pipeline entre o processo e o arquivo, e esse é um bom modelo para entender os detalhes essenciais: há duas extremidades no pipeline — uma no processo e a outra no arquivo. Este post do blog tem boas descrições do canal/pipeline de que estou falando aqui.

6>&5

A duplicação do descritor de arquivo pode ser visualizada como a criação de um segundo pipeline. O número desse pipeline é diferente no final do processo, mas a outra extremidade do novo pipeline leva ao mesmo arquivo. Os dois descritores de arquivo têm, cada um, um canal que leva ao mesmo arquivo de destino.

5>/dev/null

Posteriormente no script, o descritor de arquivo original pode ser alterado para um arquivo/dispositivo de destino diferente. Muitas descrições de redirecionamento ignoram o fato de que, quando o descritor já estava aberto, esse redirecionamento executa duas etapas em vez de uma. O canal do descritor de arquivo original (5) é fechado, removendo seu pipeline para o arquivo original, e então o descritor é aberto com um novo canal (pipeline) para o novo arquivo.

Isso não altera o descritor de arquivo duplicado (6), que ainda tem seu pipeline para o arquivo original.

5>&6

Agora, o script deseja restaurar o descritor de arquivo alterado (5) de volta ao arquivo original. O pipeline aberto para o novo destino é fechado e o descritor duplicado (6) é duplicado novamente para o descritor original (5). Agora, o descritor original é novamente conectado ao arquivo original.

6>&-

Alguns scripts agora fecham o descritor duplicado após sua finalidade ter sido cumprida. Agora, apenas o descritor original (5) é aberto para o arquivo original.

O conceito-chave é que um descritor de arquivo aberto é como um pipeline com uma extremidade no processo e a outra em um arquivo/diretório/dispositivo/fluxo/qualquer coisa. Duplicar o descritor cria algo novo na extremidade do processo, mas ele vai para o mesmo lugar na extremidade do arquivo.

Usei os descritores 5 e 6 nos meus exemplos acima, mas esse tipo de cópia de um descritor para outro descritor e sua restauração são feitos com mais frequência com os descritores para stdin (0), stdout (1) ou stderr (2).