Por que você não pode usar /dev/stderr como pipeline

O problema não é com paste, e nem com /dev/stdin. É com /dev/stderr.

Todos os comandos são criados com um descritor de entrada aberto (0: entrada padrão) e duas saídas (1: saída padrão e 2: erro padrão). Eles normalmente podem ser acessados ​​com os nomes /dev/stdin, /dev/stdoute /dev/stderrrespectivamente, mas veja Quão portáteis são /dev/stdin, /dev/stdout e /dev/stderr? . Muitos comandos, incluindo paste, também interpretarão o nome do arquivo -como STDIN.

Quando você executa bbsozinho, STDOUT e STDERR são o console, onde a saída do comando geralmente aparece. As linhas passam por diferentes descritores (como mostrado por seu annotate-output), mas acabam no mesmo lugar.

Quando você adiciona um |e um segundo comando, criando um pipeline...

bb | paste /dev/stdin /dev/stderr

o |diz ao shell para conectar a saída de bbà entrada de paste. pasteprimeiro tenta ler de /dev/stdin, que (através de alguns links simbólicos) resolve para seu próprio descritor de entrada padrão (que o shell acabou de conectar) para que a linha 1passe.

Mas o shell/pipeline não faz nada para STDERR. bbainda envia isso ( e1 e2etc.) para o console. Enquanto isso, pastetenta ler a partir do mesmo console, que trava (até você digitar algo).

Seu link Por que não consigo ler /dev/stdout com um editor de texto? ainda é relevante aqui porque essas mesmas restrições se aplicam ao /dev/stderr.

Como fazer um segundo pipeline

Você tem um comando que produz tanto a saída padrão quanto o erro padrão e deseja pasteessas duas linhas próximas uma da outra. Isso significa dois tubos simultâneos, um para cada coluna. O pipeline do shell ... | ...fornece um desses, e você precisará criar o segundo você mesmo e redirecionar o STDERR para ele usando 2>filename.

mkfifo RHS
bb 2>RHS | paste /dev/stdin RHS

Se for para uso em um script, você pode preferir fazer esse FIFO em um diretório temporário e removê-lo após o uso.

annotate-outputé capaz de fazer isso porque está fazendo algo especial (ou seja, redireciona o stderr de um comando para um fifo), algo que não pastetem absolutamente nenhuma maneira de fazer - simplesmente porque nãopaste está executando o comando (s) do qual obtém sua entrada , e não tem como redirecionar sua entrada ou sua saída.

Mas você pode escrever um wrapper que use exatamente o mesmo truque que a saída de anotação está usando:

pasteout(){
  f=$(mktemp -u) || return
  mkfifo -m 600 -- "$f" || return
  "$@" 2>"$f" | paste -- - "$f"
  rm -f -- "$f"
}
pasteout bb

Observe, no entanto, que é propenso a bloqueios. Se, por exemplo, bbproduzir mais saída padrão do que pode caber no tubo mais a quantidade extra inicialmente lida, pastemas não produzir nenhuma saída de erro, pasteserá bloqueado aguardando entrada no fifo e não esvaziará o tubo que bbestá alimentando seu stdout, fazendo com que bbos write()s do pipe também travem.

Existem alguns problemas com toda a linha que precisamos analisar, ou seja:

seq 2 | tee >(sed 's/^/e/' > /dev/stderr) | paste /dev/stdin /dev/stderr

stderr

Primeiro, o último comando. Apenas stdout pode passar por um pipe:

$ seq2 | paste -
1
2

$ seq2 | paste - -
1 2

Não há nada para ler stderr:

$ seq 2 | paste - /dev/stderr 
1   ^C

Você precisa ^Cdele porque ele bloqueia, não há nada para ler stderr.
Mesmo se você criar alguma saída para stderrela, ela não percorre um tubo:

$ { seq 2; seq 3 4 >/dev/stderr; } | paste - /dev/stderr
1   3
4

Exatamente como antes, o 1é impresso e os pasteblocos esperando por stderr.
Os outros 2 números foram diretamente para o console e foram impressos (independentemente).

Você poderia dar alguma entrada stderrno último comando do pipe:

$ { seq 2; seq 3 4 >/dev/stderr; } | paste - /dev/stderr 2</dev/null
1
2
3
4

Que é exatamente o mesmo que 2>/dev/null, aliás, para evitar bloquear o segundo descritor de arquivo usado no pastecomando. Mas os valores impressos vêm diretamente do seq 3 4redirecionado para o console, não do paste. Isso faz o mesmo:

$ { seq 2; seq 3 4 >/dev/tty; } | paste - /dev/stderr 2</dev/null
1   
2   
3
4

E isso não bloqueia:

$ seq 2 | tee >(sed 's/^/e/' > /dev/stderr) | 
  paste /dev/stdin /dev/stderr 2</dev/null
1   
2   
e1
e2

ordem

Segundo, a saída de teenão precisa estar "em ordem". Ordem de substituição do processo `tee` e `bash`

E, de fato: A saída de uma substituição de processo não precisa estar "em ordem": A saída de substituição de processo está fora de ordem

$ echo one; echo two > >(cat); echo three;
one
three
two

De fato, em alguns exemplos, se você tentar várias vezes, poderá obter pedidos diferentes. saída não determinística de processos independentes executados simultaneamente por substituição de processo

$ printf '%s\n' {0..1000} | tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null
1000
999
998
0
1

Então, não, não poderia ser feito com substituição de processo e pasta.
Você precisa dar alguma ordem para a execução:

$ seq 2 | { while read a; do printf "%s %s\n" "$a" "e$a" ; done; }
1 e1
2 e2

bb

Então, sua função bb, que (basicamente) contém:

| tee >(sed 's/^/e/')

Que poderia ser testado com:

$ printf '%s\n' {0..1000} | tee >(sort -grk1,1 | head -n3 >&2) | head -n 2
0
1
291
290
289

Deve imprimir 0, 1, 1000, 999, 998, nessa ordem, mas muitas vezes não.
Ou seja: é intrinsecamente instável.

Solução real estável.

A única solução segura para bb é evitar qualquer substituição de processo.
E, aproveitando que {…}captura tanto stdout quanto stderr, exemplo:

$ bash -c '{ echo test-str >/dev/stderr; }' 2>/dev/null

Sem saída, remova o 2 para confirmar.

Isso funcionará para bb:

$ bb() { seq 5 | tee /dev/stderr | sed 's/^/e/'; }

E use um fifo para colar:

$ mkfifo out2
$ bb 2>out2  | paste out2 -
1   e1
2   e2
3   e3
4   e4
5   e5

Você precisará definir um trap para remover o arquivo fifo e testar se o arquivo fifo existe antes de criá-lo.

Parece funcionar de forma portátil em todos os shells (compatíveis com a sintaxe Almquist) que testei. Não totalmente testado, peça confirmação de outros usuários, pode haver algumas surpresas ainda desconhecidas.