Então, eu estava procurando colocar a saída unzip -Z1em uma matriz e encontrei esta resposta ; sua primeira opção, usando mapfilee processando substituição COM redirecionamento de entrada, funciona muito bem.
Mas então pensei: "espere, substituição de processo", que cria um descritor de arquivo a partir do stdout, "então use o redirecionamento de entrada para colocar o conteúdo no stdin?"
Isso não é equivalente a apenas tubulação?
Aparentemente não. Não, não é. Aqui tento colocar o conteúdo de lsdentro de uma variável, mas usando um pipe: à la ls | mapfile -t test
Nada.
Mas, se eu seguir essa resposta para um T: id est mapfile -t test < <(ls)
Voilà.
Mas por quê? diffnão posso dizer a diferença. Pelo menos entre seu conteúdo .
Não consegui encontrar nada inerentemente especial sobre < <(), além de criar um descritor de arquivo. Usando isso como teoria, tentei um HEREDOC, que faz um descritor de arquivo também. Funcionou:
mapfile -t test2 << END && printf '%s ' "${test2[@]}"
this
is
an
array
END
Mas não se for lavado stdinvia cat, tente:
cat << END | mapfile -t test3 && printf '%s ' "${test3[@]}"
this
is
an
array
END
Então, minhas perguntas.
Essa teoria do descritor de arquivo/descoberta do HEREDOC não deveria importar mapfile, pois todos os seus manuais dizem que ele usa "entrada padrão", certo?
Se 'entrada padrão' de alguma forma significa que deve ser um descritor mais sofisticado; porque? Por que ele não consegue usar um fluxo de entrada simples de leitura única para gerar o array?
E, finalmente, se ambos forem respondidos/no caminho certo, por que o comando não falhou quando esperava um fd? Você verá que meu terminal 0imprimiu um monte (e usamos &¶ os últimos exemplos), isso está $?no meu prompt, então não houve nenhum erro relatado pelo builtin.
Eu tentei isso no Fedora 30 e RHEL 6, então não acho que seja um bug.
