Isso é um bug no bash? `return` não sai da função se chamado de um pipe

Ultimamente tenho tido problemas estranhos com o bash. Ao tentar simplificar meu script, vim com esse pequeno pedaço de código:

$ o(){ echo | while read -r; do return 0; done; echo $?;}; o
0
$ o(){ echo | while read -r; do return 1; done; echo $?;}; o
1

returndeveria ter saído da função sem imprimir $?, não deveria? Bem, então verifiquei se posso retornar de um cano sozinho:

$ echo | while read -r; do return 1; done
bash: return: can only `return' from a function or sourced script

O mesmo acontece sem um whileloop:

$ foo(){ : | return 1; echo "This should not be printed.";}
$ foo
This should not be printed.

Há algo que estou perdendo aqui? Uma pesquisa no Google não trouxe nada sobre isso! Minha versão do bash é a versão 4.2.37 (1) no Debian Wheezy.

Relacionado: /programming//a/7804208/4937930

Não é um bug que você não possa sair de um script ou retornar de uma função por exitou returnem subshells. Eles são executados em outro processo e não afetam o processo principal.

Além disso, suponho que você esteja vendo comportamentos não documentados de bash em (provavelmente) especificações indefinidas. Em uma função, nenhum erro é declarado returnno nível superior dos comandos de subshell e apenas se comporta como exit.

IMHO é um bug de bash para o comportamento inconsistente de returndepender se a declaração principal está em uma função ou não.

#!/bin/bash

o() {
    # Runtime error, but no errors are asserted,
    # each $? is set to the return code.
    echo | return 10
    echo $?
    (return 11)
    echo $?

    # Valid, each $? is set to the exit code.
    echo | exit 12
    echo $?
    (exit 13)
    echo $?
}
o

# Runtime errors are asserted, each $? is set to 1.
echo | return 20
echo $?
(return 21)
echo $?

# Valid, each $? is set to the exit code.
echo | exit 22
echo $?
(exit 23)
echo $?

Resultado:

$ bash script.sh 
10
11
12
13
script.sh: line 20: return: can only `return' from a function or sourced script
1
script.sh: line 22: return: can only `return' from a function or sourced script
1
22
23

Não é um bug, bashmas seu comportamento documentado :

Cada comando em um pipeline é executado em seu próprio subshell

A returninstrução é válida estando dentro de uma definição de função, mas estando em um subshell, ela não afeta seu shell pai, portanto a próxima instrução echoé executada independentemente. No entanto, é uma construção de shell não portátil, pois o padrão POSIX permite que os comandos que compõem um pipeline sejam executados em uma subshell (o padrão) ou na parte superior (uma extensão permitida).

Além disso, cada comando de um pipeline de comandos múltiplos está em um ambiente de subcasca; como uma extensão, no entanto, qualquer um ou todos os comandos em um pipeline podem ser executados no ambiente atual. Todos os outros comandos devem ser executados no ambiente atual do shell.

Felizmente, você pode dizer bashpara se comportar da maneira que espera com algumas opções:

$ set +m # disable job control
$ shopt -s lastpipe # do not run the last command of a pipeline a subshell 
$ o(){ echo | while read -r; do return 0; done; echo $?;}
$ o
$          <- nothing is printed here

De acordo com a documentação do POSIX, o uso de returnfora da função ou do script de origem não é especificado . Portanto, depende do seu shell para lidar.

O shell SystemV relatará erro, enquanto estiver dentro ksh, returnfora da função ou do script de origem se comportar como exit. A maioria das outras conchas POSIX e osh de schily também se comportam assim:

$ for s in /bin/*sh /opt/schily/bin/osh; do
  printf '<%s>\n' $s
  $s -c '
    o(){ echo | while read l; do return 0; done; echo $?;}; o
  '
done
</bin/bash>
0
</bin/dash>
0
</bin/ksh>
</bin/lksh>
0
</bin/mksh>
0
</bin/pdksh>
0
</bin/posh>
0
</bin/sh>
0
</bin/yash>
0
</bin/zsh>
</opt/schily/bin/osh>
0

kshe zshnão produziu porque a última parte do pipe nessas conchas foi executada no shell atual em vez do subshell. A instrução de retorno afetou o ambiente de shell atual que chamou a função, faz com que a função retorne imediatamente sem imprimir nada.

Na sessão interativa, bashapenas reporte o erro, mas não encerrou o shell, schily's oshrelatou o erro e encerrou o shell:

$ for s in /bin/*sh; do printf '<%s>\n' $s; $s -ci 'return 1; echo 1'; done
</bin/bash>
bash: return: can only `return' from a function or sourced script
1
</bin/dash>
</bin/ksh>
</bin/lksh>
</bin/mksh>
</bin/pdksh>
</bin/posh>
</bin/sh>
</bin/yash>
</bin/zsh>
</opt/schily/bin/osh>
$ cannot return when not in function

( zshNa sessão interativa e saída é fazer terminal não encerrado, bash, yashe schily's oshrelatou o erro, mas não encerrar o shell)

Eu acho que você obteve o comportamento esperado, no bash, cada comando em um pipeline é executado em um subshell. Você pode se convencer tentando modificar uma variável global de sua função:

foo(){ x=42; : | x=3; echo "x==$x";}

A propósito, o retorno está funcionando, mas retorna do subshell. Mais uma vez, você pode verificar se:

foo(){ : | return 1; echo$?; echo "This should not be printed.";}

Produzirá o seguinte:

1
This should not be printed.

Então a instrução return saiu corretamente do subshell

.

A resposta mais geral é que o bash e algumas outras conchas normalmente colocam todos os elementos de um pipeline em processos separados. Isso é razoável quando a linha de comando é

programa 1 | programa 2 | programa 3

já que os programas normalmente são executados em processos separados de qualquer maneira (a menos que você diga ). Mas pode ser uma surpresa paraexec program

comando 1 | comando 2 | comando 3

onde alguns ou todos os comandos são comandos internos. Exemplos triviais incluem:

$ a=0
$ echo | a=1
$ echo "$a"
0
$ cd /
$ echo | cd /tmp
$ pwd
/

Um exemplo um pouco mais realista é

$ t=0
$ ps | while read pid rest_of_line
> do
>     : $((t+=pid))
> done
$ echo "$t"
0

onde o todo while... do... donelaço é colocado em um subprocesso, e assim suas alterações tnão são visíveis para o shell principal após as extremidades do laço. E é exatamente isso que você está fazendo - canalizando em um whileloop, fazendo com que o loop seja executado como um subshell e, em seguida, tentando retornar do subshell.