Pourquoi ma variable est-elle locale dans une boucle "en lecture", mais pas dans une autre boucle apparemment similaire?

Pourquoi est-ce que j'obtiens des valeurs différentes pour $xles extraits ci-dessous?

#!/bin/bash

x=1
echo fred > junk ; while read var ; do x=55 ; done < junk
echo x=$x 
#    x=55 .. I'd expect this result

x=1
cat junk | while read var ; do x=55 ; done
echo x=$x 
#    x=1 .. but why?

x=1
echo fred | while read var ; do x=55 ; done
echo x=$x 
#    x=1  .. but why?

La bonne explication a déjà été donnée par jsbillings et geekosaur , mais permettez-moi de développer un peu.

Dans la plupart des shells, y compris bash, chaque côté d'un pipeline s'exécute dans un sous-shell, de sorte que toute modification de l'état interne du shell (comme la définition de variables) reste limitée à ce segment d'un pipeline. Les seules informations que vous pouvez obtenir d'un sous-shell sont ce qu'il génère (vers la sortie standard et d'autres descripteurs de fichiers) et son code de sortie (qui est un nombre compris entre 0 et 255). Par exemple, l'extrait de code suivant affiche 0:

a=0; a=1 | a=2; echo $a

Dans ksh (les variantes dérivées du code AT&T, pas les variantes pdksh / mksh) et zsh, le dernier élément d'un pipeline est exécuté dans le shell parent. (POSIX autorise les deux comportements.) L'extrait ci-dessus s'imprime donc 2.

Un idiome utile consiste à inclure la continuation de la boucle while (ou tout ce que vous avez sur le côté droit du pipeline, mais une boucle while est en fait courante ici) dans le pipeline:

cat junk | {
  while read var ; do x=55 ; done
  echo x=$x 
}

Vous rencontrez un problème de portée variable. Les variables définies dans la boucle while qui se trouve sur le côté droit du canal ont leur propre contexte de portée locale, et les modifications apportées à la variable ne seront pas vues en dehors de la boucle. La boucle while est essentiellement un sous-shell qui obtient une copie de l'environnement du shell, et toutes les modifications apportées à l'environnement sont perdues à la fin du shell. Voir cette question StackOverflow .

MISE À JOUR : J'ai négligé de souligner le fait important que la boucle while avec son propre sous-shell était due au fait qu'il s'agissait du point de terminaison d'un tuyau, je l'ai mis à jour dans la réponse.

Comme mentionné dans d'autres réponses , les parties d'un pipeline s'exécutent en sous-coquilles, donc les modifications qui y sont apportées ne sont pas visibles pour le shell principal.

Si nous considérons uniquement Bash, il existe deux autres solutions de contournement en plus de la cmd | { stuff; more stuff; }structure:

1. Rediriger l'entrée de la substitution de processus :

   while read var ; do x=55 ; done < <(echo fred)
   echo "$x"

   La sortie de la commande dans <(...)est faite pour apparaître comme s'il s'agissait d'un canal nommé.

2. L' lastpipeoption, qui fait fonctionner Bash comme ksh, et exécute la dernière partie du pipeline dans le processus shell principal. Bien que cela ne fonctionne que si le contrôle des travaux est désactivé, c'est-à-dire pas dans un shell interactif:

   bash -c '
     shopt -s lastpipe
     echo fred | while read var ; do x=55 ; done; 
     echo "$x"
   '

   ou

   bash -O lastpipe -c '
     echo fred | while read var ; do x=55 ; done; 
     echo "$x"
   '

La substitution de processus est bien sûr également prise en charge dans ksh et zsh. Mais puisqu'ils exécutent de toute façon la dernière partie du pipeline dans le shell principal, son utilisation comme solution de contournement n'est pas vraiment nécessaire.

#!/bin/bash
set -x

# prepare test data.
mkdir -p ~/test_var_global
cd ~/test_var_global
echo "a"> core.1
echo "b"> core.2
echo "c"> core.3


var=0

coreFiles=$(find . -type f -name "core*")
while read -r file;
do
  # perform computations on $i
  ((var++))
done <<EOF
$coreFiles
EOF

echo $var

Result:
...
+ echo 3
3

ça peut marcher.