Est-ce un bug dans bash? `return` ne quitte pas la fonction s'il est appelé depuis un tube

J'ai eu des problèmes étranges avec bash ces derniers temps. En essayant de simplifier mon script, j'ai trouvé ce petit morceau de code:

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

return aurait dû quitter la fonction sans imprimer $? , n'est-ce pas? Eh bien, j'ai vérifié si je pouvais revenir d'un tuyau seul:

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

La même chose se produit sans whileboucle:

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

Y a-t-il quelque chose qui me manque ici? Une recherche Google n'a rien apporté à ce sujet! Ma version bash est la version 4.2.37 (1) sur Debian Wheezy.

En relation: /programming//a/7804208/4937930

Ce n'est pas un bug que vous ne pouvez pas quitter un script ou retourner d'une fonction par exitou returnen sous-shell. Ils sont exécutés dans un autre processus et n'affectent pas le processus principal.

En plus de cela, je suppose que vous voyez des comportements non documentés de bash sur (probablement) des spécifications non définies. Dans une fonction, aucune erreur n'est affirmée returnau niveau supérieur des commandes de sous-shell et elle se comporte simplement comme exit.

À mon humble avis, c'est un bogue bash pour le comportement incohérent de returnselon que l'instruction principale est dans une fonction ou non.

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

Production:

$ 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

Ce n'est pas un bug bashmais son comportement documenté :

Chaque commande d'un pipeline est exécutée dans son propre sous-shell

L' returninstruction est valide étant à l'intérieur d'une définition de fonction mais étant également dans un sous-shell, elle n'affecte pas son shell parent donc l'instruction suivante,, echoest exécutée malgré tout. Il s'agit néanmoins d'une construction shell non portable car le standard POSIX permet aux commandes composant un pipeline d'être exécutées soit dans un sous-shell (par défaut) soit dans le top (une extension autorisée).

De plus, chaque commande d'un pipeline multi-commandes se trouve dans un environnement de sous-shell; cependant, en tant qu'extension, une ou toutes les commandes d'un pipeline peuvent être exécutées dans l'environnement actuel. Toutes les autres commandes doivent être exécutées dans l'environnement shell actuel.

Avec un peu de chance, vous pouvez dire bashde vous comporter comme vous le souhaitez avec quelques options:

$ 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

Selon la documentation POSIX, l' utilisation en returndehors de la fonction ou du script source n'est pas spécifiée . Cela dépend donc de votre shell à gérer.

Le shell SystemV signalera une erreur, tandis que dans ksh, en returndehors de la fonction ou du script source se comportera comme exit. La plupart des autres shells POSIX et l' os de schily se comportent également comme ça:

$ 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

kshet zshn'a pas été généré car la dernière partie du tuyau dans ces shells a été exécutée dans le shell actuel au lieu de sous-shell. L'instruction return a affecté l'environnement shell actuel qui a appelé la fonction, provoquant le retour immédiat de la fonction sans rien imprimer.

Dans une session interactive, bashsignalez uniquement l'erreur mais n'avez pas terminé le shell, schily's oshsignalé l'erreur et terminé le 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

( zshdans la session interactive et la sortie est le terminal ne s'est pas terminé bash, yashet a schily's oshsignalé l'erreur mais n'a pas terminé le shell)

Je pense que vous avez obtenu le comportement attendu, en bash, chaque commande dans un pipeline est exécutée en sous-shell. Vous pouvez vous convaincre en essayant de modifier une variable globale de votre fonction:

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

Soit dit en passant, le retour fonctionne mais il revient du sous-shell. Encore une fois, vous pouvez vérifier que:

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

Sortira les éléments suivants:

1
This should not be printed.

Donc, l'instruction de retour a correctement quitté le sous-shell

.

La réponse plus générale est que bash et certains autres shells placent normalement tous les éléments d'un pipeline dans des processus séparés. Ceci est raisonnable lorsque la ligne de commande est

programme 1 | programme 2 | programme 3

puisque les programmes sont normalement exécutés dans des processus séparés de toute façon (sauf si vous dites ). Mais cela peut surprendreexec program

commande 1 | commande 2 | commande 3

où certaines ou toutes les commandes sont des commandes intégrées. Des exemples triviaux comprennent:

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

Un exemple un peu plus réaliste est

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

où l'ensemble while... do... la doneboucle est mis dans un sous - processus, et ainsi ses modifications tne sont pas visibles sur la coque principale après la fin de la boucle. Et c'est exactement ce que vous faites: canaliser dans une whileboucle, faire fonctionner la boucle en tant que sous-shell, puis essayer de revenir du sous-shell.