È un bug in bash? `return` non esce dalla funzione se chiamato da una pipe

Ultimamente ho avuto strani problemi con bash. Durante il tentativo di semplificare il mio script, ho trovato questo piccolo pezzo di codice:

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

returnavrebbe dovuto uscire dalla funzione senza stampare $?, no? Bene, quindi ho verificato se posso tornare da una pipa da solo:

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

Lo stesso succede senza whileloop:

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

C'è qualcosa che mi manca qui? Una ricerca su Google non ha apportato nulla al riguardo! La mia versione bash è 4.2.37 (1)-release su Debian Wheezy.

Correlato: /programming//a/7804208/4937930

Non è un bug che non è possibile uscire da uno script o tornare da una funzione di exito returnin subshells. Vengono eseguiti in un altro processo e non influiscono sul processo principale.

Inoltre, suppongo che tu stia vedendo comportamenti non documentati di bash su specifiche (probabilmente) indefinite. In una funzione, non viene affermato alcun errore per il returnlivello superiore dei comandi subshell e si comporta come exit.

IMHO è un bug bash per il comportamento incoerente di returndipendere dal fatto che l'istruzione principale sia o meno in una funzione.

#!/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 $?

Produzione:

$ 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

Non è un bug bashma il suo comportamento documentato :

Ogni comando in una pipeline viene eseguito nella propria subshell

L' returnistruzione è valida all'interno di una definizione di funzione ma anche in una sottostruttura, non influisce sulla sua shell madre, quindi l'istruzione successiva echoviene eseguita indipendentemente. Si tratta tuttavia di una costruzione shell non portatile poiché lo standard POSIX consente di eseguire i comandi che compongono una pipeline in una subshell (impostazione predefinita) o in quella superiore (un'estensione consentita).

Inoltre, ogni comando di una pipeline multi-comando si trova in un ambiente subshell; come estensione, tuttavia, qualsiasi o tutti i comandi in una pipeline possono essere eseguiti nell'ambiente corrente. Tutti gli altri comandi devono essere eseguiti nell'attuale ambiente shell.

Eventualmente, puoi dire bashdi comportarti come ti aspetti con un paio di opzioni:

$ 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

Per la documentazione POSIX, l' utilizzo returnal di fuori della funzione o dello script di provenienza non è specificato . Quindi, dipende dalla shell da gestire.

La shell di SystemV segnalerà un errore, mentre in ksh, returnal di fuori della funzione o lo script di origine si comporta come exit. Anche la maggior parte delle shell POSIX e l'osh di schily si comportano così:

$ 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 zshnon l'output perché l'ultima parte della pipe in queste shell è stata eseguita nella shell corrente invece che nella subshell. L'istruzione return ha influito sull'ambiente shell corrente che ha chiamato la funzione, causa immediatamente il ritorno della funzione senza stampare nulla.

Nella sessione interattiva, bashsegnala solo l'errore ma non ha terminato la shell, ha schily's oshsegnalato l'errore e ha terminato la 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

( zshIn sessione e output interattivo è do terminale non chiuso, bash, yashe schily's oshsegnala l'errore, ma non è terminato il guscio)

Penso che tu abbia il comportamento atteso, in bash, ogni comando in una pipeline viene eseguito in una subshell. Puoi convincerti cercando di modificare una variabile globale della tua funzione:

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

A proposito, il ritorno sta funzionando ma ritorna dalla subshell. Ancora una volta puoi controllare che:

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

Produrrà quanto segue:

1
This should not be printed.

Quindi l'istruzione return è uscita correttamente dalla subshell

.

La risposta più generale è che bash e alcune altre shell normalmente mettono tutti gli elementi di una pipeline in processi separati. Questo è ragionevole quando la riga di comando è

programma 1 | programma 2 | programma 3

poiché i programmi vengono normalmente eseguiti in processi separati comunque (a meno che non lo dica ). Ma può essere una sorpresa perexec program

comando 1 | comando 2 | comando 3

dove alcuni o tutti i comandi sono comandi integrati. Esempi fondamentali includono:

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

Un esempio leggermente più realistico è

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

dove l'intero ciclo while... do... doneviene inserito in un sottoprocesso, e quindi le sue modifiche tnon sono visibili alla shell principale al termine del ciclo. Ed è esattamente quello che stai facendo: eseguire il piping in un whileloop, far sì che il loop venga eseguito come subshell e quindi provare a tornare dalla subshell.