Então você quer canalizar a saída de cmd1 para cmd2 e cmd3 e obter a saída de cmd2 e cmd3 em diferentes variáveis?

Então parece que você precisa de dois tubos do shell, um conectado à saída do cmd2 e outro à saída do cmd3, e o shell para usar select()/ poll()para ler esses dois tubos.

bashnão serve para isso, você precisaria de um shell mais avançado como zsh. zshnão tem uma interface bruta para pipe(), mas se estiver no Linux, você pode usar o fato de que /dev/fd/xem um pipe regular funciona como um pipe nomeado e usar uma abordagem semelhante à usada em Ler/gravar no mesmo descritor de arquivo com redirecionamento de shell

#! /bin/zsh -

cmd1() seq 20
cmd2() sed 's/1/<&>/g'
cmd3() tr 0-9 A-J

zmodload zsh/zselect
zmodload zsh/system
typeset -A done out
{
  cmd1 > >(cmd2 >&3 3>&-) > >(cmd3 >&5 5>&-) 3>&- 5>&- &
  exec 4< /dev/fd/3 6< /dev/fd/5 3>&- 5>&-
  while ((! (done[4] && done[6]))) && zselect -A ready 4 6; do
    for fd (${(k)ready[(R)*r*]}) {
      sysread -i $fd && out[$fd]+=$REPLY || done[$fd]=1
    }
  done
} 3> >(:) 5> >(:)

printf '%s output: <%s>\n' cmd2 "$out[4]" cmd3 "$out[6]"

Se eu entendi bem todos os seus requisitos, você pode conseguir isso bashcriando um canal sem nome por comando, redirecionando a saída de cada comando para seu respectivo canal sem nome e, finalmente, recuperando cada saída de seu canal em uma variável separada.

Assim, a solução pode ser assim:

: {pipe2}<> <(:)
: {pipe3}<> <(:)

command1 | tee >({ command2 ; echo EOF ; } >&${pipe2}) >({ command3 ; echo EOF ; } >&${pipe3}) > /dev/null &
var2=$(while read -ru ${pipe2} line ; do [ "${line}" = EOF ] && break ; echo "${line}" ; done)
var3=$(while read -ru ${pipe3} line ; do [ "${line}" = EOF ] && break ; echo "${line}" ; done)

exec {pipe2}<&- {pipe3}<&-

Aqui, observe particularmente:

• o uso do <(:)construto; este é um truque não documentado do Bash para abrir pipes "sem nome"
• o uso de um simples echo EOFcomo forma de notificar os whileloops de que não haverá mais saída. Isso é necessário porque não adianta apenas fechar os pipes sem nome (que normalmente terminariam qualquer while readloop) porque esses pipes são bidirecionais, ou seja, usados ​​tanto para escrita quanto para leitura. Não conheço nenhuma maneira de abri-los (ou convertê-los) no par usual de descritores de arquivo, um sendo o final de leitura e o outro o final de gravação.

Neste exemplo, usei uma abordagem de bash puro (além do uso de tee) para esclarecer melhor o algoritmo básico exigido pelo uso desses pipes sem nome, mas você poderia fazer as duas atribuições com alguns sedno lugar dos whileloops, como em var2="$(sed -ne '/^EOF$/q;p' <&${pipe2})"para variável2 e seu respectivo para variável3, produzindo o mesmo resultado com muito menos digitação. Ou seja, tudo seria:

Solução enxuta para pequena quantidade de dados

: {pipe2}<> <(:)
: {pipe3}<> <(:)

command1 | tee >({ command2 ; echo EOF ; } >&${pipe2}) >({ command3 ; echo EOF ; } >&${pipe3}) > /dev/null &
var2="$(sed -ne '/^EOF$/q;p' <&${pipe2})"
var3="$(sed -ne '/^EOF$/q;p' <&${pipe3})"

exec {pipe2}<&- {pipe3}<&-

Para exibir as variáveis ​​de destino, lembre-se de desabilitar a divisão de palavras limpando o IFS, assim:

IFS=
echo "${var2}"
echo "${var3}"

caso contrário, você perderia novas linhas na saída.

O acima parece uma solução bastante limpa, de fato. Infelizmente, ele só pode funcionar para uma saída não muito grande, e aqui sua milhagem pode variar: em meus testes, encontrei problemas em cerca de 530k de saída. Se você estiver dentro do limite (bem muito conservador) de 4k, você deve estar bem.

A razão para esse limite está no fato de que duas atribuições como essas, ou seja , sintaxe de substituição de comandos , são operações síncronas, o que significa que a segunda atribuição é executada somente após a conclusão da primeira, enquanto pelo contrário teealimenta os dois comandos simultaneamente e bloqueando todos deles se algum deles preencher seu buffer de recebimento. Um impasse.

A solução para isso requer um script um pouco mais complexo, para esvaziar os dois buffers simultaneamente. Para este fim, um whilelaço sobre os dois tubos seria útil.

Uma solução mais padrão para qualquer quantidade de dados

Um Bashismo mais padrão é como:

declare -a var2 var3
while read -r line ; do
   case "${line}" in
   cmd2:*) var2+=("${line#cmd2:}") ;;
   cmd3:*) var3+=("${line#cmd3:}") ;;
   esac
done < <(
   command1 | tee >(command2 | stdbuf -oL sed -re 's/^/cmd2:/') >(command3 | stdbuf -oL sed -re 's/^/cmd3:/') > /dev/null
)

Aqui você multiplexa as linhas de ambos os comandos no único descritor de arquivo “stdout” padrão e, em seguida, desmultiplexa a saída mesclada em cada variável respectiva.

Observe particularmente:

• o uso de arrays indexados como variáveis ​​de destino: isso ocorre porque apenas anexar a uma variável normal se torna terrivelmente lento na presença de muita saída
• o uso de sedcomandos para preceder cada linha de saída com as strings "cmd2:" ou "cmd3:" (respectivamente) para o script saber a qual variável cada linha pertence
• o uso necessário de stdbuf -oLpara definir o buffer de linha para a saída dos comandos: isso ocorre porque os dois comandos aqui compartilham o mesmo descritor de arquivo de saída e, como tal, eles substituiriam facilmente a saída um do outro na condição de corrida mais típica se acontecerem de transmitir dados ao mesmo tempo; saída de buffer de linha ajuda a evitar que
• note também que tal uso de stdbuf só é necessário para o último comando de cada cadeia, ou seja, aquele que sai diretamente para o descritor de arquivo compartilhado, que neste caso são os comandos sed que precedem a saída de cada comandoX com seu prefixo distinto

Uma maneira segura de exibir adequadamente esses arrays indexados pode ser assim:

for ((i = 0; i < ${#var2[*]}; i++)) ; do
   echo "${var2[$i]}"
done

Claro que você também pode usar "${var2[*]}"como em:

echo "${var2[*]}"

mas isso não é muito eficiente quando há muitas linhas.

Encontrei algo que parece funcionar bem:

exec 3<> <(:)
var3=$(command1 | tee >(command2 >&3) | command3)
var2=$(while IFS= read -t .01 -r -u 3 line; do printf '%s\n' "$line"; done)

Ele funciona definindo um canal anônimo <(:)para o descritor de arquivo 3 e canalizando a saída command2para ele. var3captura a saída de command3e a última linha lê do descritor de arquivo 3 até que não receba nenhum dado novo por 0,01 segundo.

Ele só funciona para uma saída de até 65536 bytes, dos command2quais parecem ser armazenados em buffer pelo pipe anônimo.

Eu não gosto da última linha da solução. Prefiro ler tudo de uma vez e não esperar 0,01 segundo, mas parar assim que o buffer estiver vazio. Mas eu não conheço nenhuma maneira melhor.

Isso é possível desde 4.0. bash adicionou uma palavra reservada do shell coproc. Ele bifurca o comando que segue para segundo plano como um subprocesso (que normalmente não permitiria a passagem de variáveis.), porém cria um array (padrão COPROC, mas pode ser nomeado). ${COPROC[0]} se conecta à entrada padrão do subprocesso ${COPROC 1 } sua saída padrão. Esses processos podem ser manipulados como tarefas, são assíncronos, então você pode usar apenas tee para canalizar para os dois coprocessos e ter eles saem para um arquivo separado, cada um deles combinando as saídas no valor de retorno de cada um chamando "${COPROCFIRST 1 } ${COPROCSECOND 1 }", o que é ótimo porque nem precisa estar dentro do pipeline.

bash coproc command_1 { command1 arg1 arg2 arg3 >> command_1_output.txt } coproc command_2 { command2 arg1 arg2 arg3 >> command_2_output.txt } othercommand | tee >^${command_1 1 }" >&"${command_2 1 }" read -r resultados1 <&"${command_1[0]" read -r resultados2 <&"${command_2[0]" echo "$result1 $result2" | command3 >> resultado combinado.txt

Como mencionado, esta solução está atualmente incompleta, então estou atacando, no entanto, o princípio é sólido e é semelhante à resposta acima. No entanto, vou direcioná-lo para alguns bons artigos sobre o assunto e retornarei a esta resposta quando o trabalho permitir.

Exemplo de configuração de variáveis ​​em um coprocesso

Análise detalhada do coprocessamento e dos pipes nomeados

Usos e armadilhas