Como capturar stderr da função que modifica o ambiente atual?

Tanto o Bash quanto o zsh têm coprocessos (infelizmente um pouco diferentes), que basicamente encerram uma pipechamada e geram um subprocesso com sua entrada e saída padrão disponíveis para o shell de chamada. Em essência, eles permitem que o shell seja reproduzido xem , mas com todos y, e executando a partir do processo atual e não em um ambiente de execução de pipeline.x | cmd | yxycmd

Isso nos permitirá executar module 2>&...alguns ..., moduleexecutando a partir do shell atual. Se usarmos catcomo nosso coprocesso (ou seja cmd, ), ele apenas repetirá tudo de volta novamente e, em seguida, poderemos ler a saída de volta no shell atual novamente y <&...mais tarde.

Outra opção é redirecionar o erro padrão para outro processo em segundo plano e waitpara seu código de retorno. Vou abordar ambos abaixo.

Vou usar esta modulefunção falsa para testar para que eu possa ativar e desativar erros à vontade. If modifica o ambiente shell atual para que possamos vê-lo e gera "err" para stderr; Estarei comentando essa linha dentro e fora conforme necessário:

module() {
        sleep 1
        FOO=$(date)
        echo err >&2
} 

Se eu executar um catcoprocesso no Bash, posso redirecionar moduleo stderr de 's para isso e ler cato stdout de 's para fazer o que eu quiser:

coproc cat
module 2>&${COPROC[1]}
exec {COPROC[1]}>&-
if grep -q err <&${COPROC[0]}
then
        echo got an error
else
        echo no error
fi

Em zsh precisa ser

module 2>&p
exec 4<&p
coproc :
if grep -q err <&4

no meio em vez disso.

Em ambos os casos, posso executar o modulecomando no shell atual e ler a saída de erro lá. Uma função pode retornar dentro do ifnormal.

Tudo, exceto catestá sendo executado a partir do ambiente de execução atual: os redirecionamentos FD não criam ambientes independentes como os pipelines. Podemos echo $FOOno final verificar isso, e ver se a data foi atualizada porque moduleexecutou no ambiente atual.

Alternativamente, o processo em segundo plano poderia fazer todo o trabalho. Isso funciona no Bash:

exec 2> >( if grep -q . ; then exit 7 ; else exit 0 ; fi )
PID=$!
module
exec 2>&-
wait $PID
echo $?

O resultado acima será 7ou 0de acordo com o que o subprocesso no topo disse - você pode ajustar para fazer o que quiser sobre o código de retorno. Sob zsh, não, porque $!não está definido para substituições de processos; isso deveria ser solucionável, mas eu parei de tentar. Um fifo fixo, em vez de um arquivo temporário, também funcionaria aqui.

Nesse caso, você provavelmente deseja salvar e restaurar o FD 2 em ambos os lados também.

Não sei como os "Módulos de ambiente" funcionam, mas assumirei pela sua descrição que são funções de shell que definem variáveis ​​de ambiente e sua saída stderr deve ser capturada / correspondida sem executá-las em um processo separado.

A resposta, goste ou não, é que a única maneira robusta e óbvia é redirecionar seu stderr para um arquivo temporário. Usar pipes nomeados é tão complicado (você ainda precisa criar um arquivo temporário!), além de ser muito mais complicado. E o uso de coprocessos é oneroso, incômodo e não portátil .

Em bash(e bashapenas em) você pode tirar proveito de um recurso não documentado ( $!sendo definido para o PID de uma >(...)substituição de processo) e se safar com algo como:

module 2> >(grep error)
wait $! && echo failed

Este exemplo assume que moduleele próprio não está gerando nenhum filho que possa confundir $!.

No Linux, com bash e zsh, você deve ser capaz de fazer:

my_module() {
  chmod u+w /dev/fd/3 # only needed in bash 5+
  module 2> /dev/fd/3 3>&-
  ! grep -q err /dev/fd/3
} 3<<< ''

O 3<<< ''é uma string here contendo inicialmente uma linha vazia. Ambos zshe bashimplementam here-strings e here-documents como arquivos temporários excluídos. No Linux (e Cygwin, mas geralmente não em outros sistemas), a abertura /dev/fd/3abre o arquivo apontado pelo fd 3, mesmo que já tenha sido excluído (em outros sistemas, duplica o fd 3), por isso é uma maneira muito limpa de trabalhar com arquivos temporários lá. O arquivo já foi deletado, você não precisa se preocupar com sua limpeza, e ele só fica visível no FS por um tempo muito curto (desde a versão 5, no entanto, bashremove as permissões de gravação para ele com as quais precisamos trabalhar chmod).

Aqui, você precisa de um arquivo temporário se for executar modulee grepem sequência (em oposição a em paralelo em processos separados). Fazer isso com tubos (como nas abordagens de Michael, mas ao contrário do @mosvy) levaria a bloqueios se houver saída de dados suficiente para preencher os tubos.