Noções básicas sobre if-statement redirecionada no bash

Question

if [ -z "$OPTION" ] # if option is not given(empty) then:
    then
        command1 --defaultOption
    else 
        command1 $OPTION
fi \
  2> >( function1 "$DETAILS" ) \
  < <( command2 "$OTHER_DETAILS" )

Estou seriamente intrigado em como direcionar o stderr para um arquivo e alimentar um arquivo no stdin interage com uma instrução if. Coisas bem conhecidas são: 2>filename# Redirect stderr to file "filename." 2>>filename# Redirect and append stderr to file "filename." command < input-file > output-file < input-file command > output-file

Meu palpite seria:

o comando2 gera um arquivo que é encaminhado para o stdin do comando1 com --defaultOption (se $ OPTION estiver vazio, então caso) ou para o stdin do comando1 com $ OPTION (se $ OPTION não estiver vazio, caso contrário). stderr do comando1 é redirecionado para a função1 (que, por exemplo, pode ser algum tipo de exibição da barra de progresso).

Então, minhas perguntas são:

Os espaços em branco entre os colchetes são < < e > > necessários? É real um acréscimo (espaço em branco ignorado) ou um redirecionamento "duplo"? Estou faltando uma interação entre colchetes e chaves >( e <( ? Isso de alguma forma influencia a avaliação do if? Ou é apenas -z $OPTION testado?

Posso entender melhor o que está acontecendo se eu gravar o arquivo de saída do comando2 no disco e, em seguida, verificar a opção e lê-la novamente na instrução if?

command2 "$OTHER_DETAILS" --out=file.txt
if [ -z "$OPTION]
  then
    command1 --defaultOption --in=file.txt 2>function1
  else
    command1 "$OPTION" --in=file.txt 2>function1
fi

Isso faz parte de um script que encontrei por lá: link (linhas 912 a 924)

    

Answer 1

<(cmd) e >(cmd) são a gramática da shell (chamada de substituição de processo). Eles são substituídos por um caminho de arquivo, por exemplo,

cmd1 <(cmd2)

torna-se

cmd1 /path/to/file

O conteúdo do arquivo é a saída de cmd2 , portanto, ele pode ser lido apenas, mas não gravado. Um exemplo:

start cmd:> ls -l <(echo foo)
lr-x------ 1 hl hauke 64  5. Jan 03:49 /dev/fd/63 -> pipe:[3125128]

Nesse caso, ls vê /dev/fd/63 como argumento. No seu caso, esse caminho se torna parte de um redirecionamento. Assim, o espaço em branco é obrigatório. > >(cmd) é "stdout de redirecionamento para um arquivo temporário cujo conteúdo se torna a entrada de cmd", enquanto >>(cmd) causa um erro porque o shell espera um caminho (ou espaço em branco) após >> . >>'(cmd)' "funciona" porque agora (cmd) é considerado um arquivo:

start cmd:> echo foo >>'(cat)'

start cmd:> cat \(cat\) 
foo

    

Answer 2

Um >( ) é um idioma chamado "Substituição de Processo" e é usado para substituir algum código ou função por "o lugar de um arquivo".

O >( function1 "$DETAILS" ) está se conectando ao stdin de function1 . A julgar pelo nome, eu assumo que function1 é uma função já definida (no código lido antes onde a função está sendo usada) no script que você está usando / lendo. Qualquer comando que escolha se conectar a stdin (muitas vezes cat) dentro de function1 lerá a entrada de stdin

Da mesma forma, <( command2 "$OTHER_DETAILS" ) está se conectando ao stdout de command2 (que, assumirei, é uma função dentro do script). Qualquer echo , printf e muitos outros poderiam gravar para stdout de dentro do código de command2 .

O resultado final é que stderr (2 >) do código executado dentro do if está sendo conectado a algum outro código dentro do script. E a saída do command2 também está sendo conectada ao código dentro do if (que deve ser o comando 1 a julgar pelo código apresentado).

As duas re-indicações são semelhantes (não exatamente iguais) a este código:

command2     | command1
command1 2>1 | function1