Duplicar stdout para canalizar para outro comando com pipe nomeado na função de script de shell POSIX

O cerne do problema é que o POSIX tem aquele requisito (geralmente inútil) de shque os comandos assíncronos devem ter seu stdin redirecionado, /dev/nulla menos que haja um redirecionamento stdin explícito (bem, tecnicamente, esse /dev/nullredirecionamento implícito acontece antes dos redirecionamentos explícitos, se houver).

Veja, por exemplo, em sistemas baseados em Linux:

$ sh -c 'realpath /dev/stdin & wait'
/dev/null

Uma solução alternativa comum para que o comando assíncrono não tenha seu stdin alterado é fazer algo como:

{ cmd <&3 3<&- & } 3<&0

Onde o stdin original é disponibilizado no fd 3, além de 0 em um grupo de comando com 3<&0, e dentro do cmdstdin do grupo de comando, que foi reaberto em /dev/nullporque &está sendo redirecionado de volta para o stdin original por meio desse fd 3 (que então fechamos porque não é mais necessário).

Em:

f() (
  mkfifo foo
  tee foo &
  tr -s '[:lower:]' '[:upper:]' <foo
  rm foo
)
printf %s\\n bar | f

teeO stdin do será /dev/null, não a extremidade de leitura do pipe de printf. Alterando para:

f() (
  mkfifo foo
  { tee foo <&3 3<&- & } 3<&0
  tr -s '[:lower:]' '[:upper:]' <foo
  rm foo
  wait
)
printf '%s\n' bar | f

Iria abordar isso, mas como você descobriu, também o faria

f() (
  mkfifo foo
  tr -s '[:lower:]' '[:upper:]' <foo &
  tee foo
  rm foo
)
printf %s\\n bar | f

Como ele teenão é executado de forma assíncrona, portanto não tem seu stdin redirecionado /dev/nulle tro stdin do está sendo redirecionado explicitamente, não importa que ele tenha sido redirecionado /dev/nullanteriormente.

Também não precisamos do wait, pois teeo processo está sendo executado de forma síncrona (atrasado do que foi implicitamente esperado pelo shell) e normalmente não seria encerrado antes, trpois está esperando por eof em seu stdin (e tro stdout de , que é a outra extremidade desse pipe, só é fechado na saída).

Talvez você ainda queira esperar trpara recuperar seu status de saída:

f() (
  ret=0
  mkfifo foo || exit
  tr -s '[:lower:]' '[:upper:]' <foo &
  tee foo || ret=$?
  rm -f foo
  wait "$!" || ret=$?
  exit "$ret"
)
printf '%s\n' bar | f

foonão será removido se o subshell que é o corpo da função for morto. Você pode reduzir a janela durante a qual o fifo existe e torná-lo ainda mais parecido com um pipe sem nome (onde o pipe nomeado é apenas um ponto de encontro efêmero para esses dois processos estabelecerem um pipe), removendo-o assim que for aberto tanto no modo de leitura quanto de gravação pelos dois processos.

f() (
  ret=0
  mkfifo foo || exit
  { tee foo <&3 3<&- & } 3<&0
  {
    # at that point, foo will have been opened here in read-only mode
    # on stdin which can only happen if tee has opened it in write-only 
    # mode already.
    rm -f foo
    tr -s '[:lower:]' '[:upper:]' || ret=$?
  } < foo
  wait "$!" || ret=$?
  exit "$ret"
)
printf '%s\n' bar | f

Parece que o problema é, como suspeito, tentar canalizar external_programpara um arquivo tee.

No roteiro original, havia:

printf %s\\n bar | tee foo &

Que não desvincula tee(apenas), mas toda a sequência de pipe em uma. Então o que eu originalmente fiz foi um pipe como esse, que é resolvido imediatamente, ou seja, ambos sleepe noop :são desvinculados juntos:

$ time sh -c 'sleep 10 | : &'

real    0m0.001s
user    0m0.000s
sys     0m0.001s

No entanto, ao detaching teedentro da função, foi somente teeisso que foi detached, não o programa externo no começo do pipe. Reutilizando o exemplo com sleep, podemos ver que apenas noop :é detached, mas sleepnão, e o script leva os 10 segundos completos:

$ time sh -c 'sleep 10 | { : & }'

real    0m10.002s
user    0m0.002s
sys     0m0.000s

A solução não é detach tee, mas sim o outro comando:

f() (
  mkfifo foo
  tr -s '[:lower:]' '[:upper:]' <foo &
  tee foo
  wait
  rm foo
)
printf %s\\n bar | f

Agora teeé possível receber stdout do pipe, escrever no FIFO e a saída da função é novamente:

bar
BAR