Por que `... | sed 's/^/stdout: /'` imprime em stdin vazio quando `... > >(sed 's/^/stdout: /')` não?

Seu primeiro comando,

( echo foo >&2 ) 2> >(sed 's/^/stderr: /') | sed 's/^/stdout: /'

de forma simplificada (usando um arquivo temporário para armazenar os dados produzidos por echo):

{ echo foo 2>file >&2; sed 's/^/stderr: /' file; } | sed 's/^/stdout: /'

Ou seja, o primeiro sedlê o que é produzido no erro padrão do echoe grava na saída padrão e o segundo sedlê e modifica isso.

Seu segundo comando,

( echo foo >&2 ) 2> >(sed 's/^/stderr: /') > >(sed 's/^/stdout: /')

de forma simplificada,

echo foo 2>file >&2; sed 's/^/stderr: /' file; sed 's/^/stdout: /' </dev/null

Aqui, o sedque obtém a saída de erro padrão produz saída, enquanto o outro sedque obtém a saída de saída padrão (que não é nada) não produz nenhuma saída (já que não obteve nenhuma entrada e não inseriu ou anexou nenhum dado) .

Outra forma de formular:

Primeiro comando:

( echo foo >&2 ) 2>file
sed 's/^/stderr: /' file | sed 's/^/stdout: /'

Segundo comando:

( echo foo >&2 ) 2>file >otherfile
sed 's/^/stderr: /' file
sed 's/^/stdout: /' otherfile

Em suma, o segundo sedno segundo comando nunca lê nada. Em particular, ele não lê a saída do primeiro sedcomo no primeiro comando.

Usando símbolos extremamente simplificados, o primeiro comando é algo como

utility-writing-to-stderr 2> >(something1) | something2

onde something1grava na saída padrão, que é lida por something2.

O segundo comando, usando a mesma notação,

utility-writing-to-stderr 2> >(something1) >(something2)

ou seja something1, e something2nem mesmo está conectado entre si, e something2não pode de forma alguma ler o que something1está produzindo. Além disso, como utility-writing-to-stderrnão produz nada em seu fluxo de saída padrão, something2não terá nada para ler de sua entrada padrão.

>está operando ( echo foo >&2 )e |está operando por >(sed 's/^/stderr: /')causa da ordem de redirecionamento nos shells. POR EXEMPLO

$ ( echo foo >&2 ) 2> >(sed 's/^/stderr: /' > >(sed 's/^/stdout: /') )
stdout: stderr: foo

ou

$ ( echo foo >&2 ) 2> >(sed 's/^/stderr: /') | cat > >(sed 's/^/stdout: /')
stdout: stderr: foo

vs exemplos explícitos a ordem na pergunta

$ ( ( echo foo >&2 ) > >(sed 's/^/stdout: /') ) 2> >(sed 's/^/stderr: /')
stderr: foo

ou

$ ( ( echo foo >&2 )  | sed 's/^/stdout: /' ) 2> >(sed 's/^/stderr: /')
stderr: foo

Os dois comandos não são equivalentes.

O comando (1):

( one ) 2> >(two) | three 

Envia a saída (std) de twopara three(Mais sobre stderr abaixo).

O comando (2):

( one ) 2> >(two) > >(three)

Envia a saída (std) de onepara three(stderr vai para two).

O detalhe doloroso é:

Comando 1:( one ) 2> >(two) | three

• O comando threeé iniciado ( sed 's/^/stdout: /') aguardando entrada em stdin.
• O redirecionamento de 2( stderr) para o stdinde twoocorre.
• O redirecionamento interno de oneocorre ( echo foo >&2).
• O comando é executado enviando foopara stderr(nada para stdout).
• A palavra fooé redirecionada de ( stderrde one) para ( stdinde two).
• O comando em dois é executado ( sed 's/^/stderr: /')
• A saída agora modificada de two( stderr: foo) é enviada para o stdout de two.
• O stdout atual de twopassa pelo pipe para three.
• O comando threeque estava aguardando entrada desde o início obtém a saída.
• A saída é modificada adicionando um stdout:.
• A string final stdout: stderr: foovai para tty.

Comando 2: (um) 2> >(dois) > >(três)

• O último redirecionamento ( >) é construído primeiro.
• O comando threeé iniciado aguardando entrada stdin somente em ( >()).
• O comando threeobtém apenas o stdout de one.
• O comando twoé iniciado aguardando entrada.
• O comando twoobtém ( somente ) o stderr de one.
• O redirecionamento interno de um conecta o stdout de oneao seu stderr.
• O comando oneé executado enviando foopara o stderr(de one).
• foovai paratwo
• twoaltera a string recebida para stderr: fooe a envia para tty .
• threerecebe uma entrada vazia do stdout de one.
• threenão imprime nada (já que não há linha para processar).

Entenda que este comando:

printf '' | sed 's/^/initial: /'

não tem saída (e não há como fazê-lo funcionar).

Mudando a ordem: Comando 3: (um) > >(três) 2> >(dois)

Faz com que a saída do detalhe twová para three(não o ) fique como um exercício.tty

Eu votei na resposta muito clara de @Kusalananda, mas me arrisco a (tardiamente) adicionar isso à sua resposta, como uma pequena ilustração da substituição do processo em funcionamento:

Sua segunda proposição funcionaria com uma pequena mudança tipográfica (e uma mudança comparativamente grande em sua lógica defeituosa):

  $ ( echo foo >&2 ) 2> >(sed 's/^/stderr: /') > >(sed 's/^/stdout: /')
  stderr: foo    # for the well explained reason above

Mas:

    v                                          vv
  $ ( (echo foo >&2) 2> >(sed 's/^/stderr: /') )> >(sed 's/^/stdout: /')  
  stdout: stderr: foo

Porque adicionar ( )>conforme ilustrado (ou >( ), ambos funcionam bem) na verdade permite que você crie um arquivo por meio de substituição de processo, cuja saída pode ser redirecionada como entrada para >(sed 's/^/stdout: /').

Pensei em adicionar isso para ilustrar como a substituição de processo pode ser incorporada em outra substituição de processo. Para facilitar a leitura, eu não o empurraria para mais níveis de incorporação. Mas se por algum motivo você precisar evitar um pipe e o shell associado , esta é uma boa solução.