Discussion :

[gRRosminet]

Bonjour,

J'aimerai comprendre soit le pourquoi, soit le comment faire de la gestion des variables d'environnement dans une boucle while et surtout de leur propagation

Voici deux exemples de code semblables mais qui ne donnent pas le même résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
FILE_ID=0
ls -w 1 /home | while read file
do
    echo "$FILE_ID"
    FILE_ID=$(( $FILE_ID + 1 ))
done
echo "final : $FILE_ID"

0
1
2
3
4
5
final : 0

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
FILE_ID=0
while read file
do
    echo "$FILE_ID"
    FILE_ID=$(( $FILE_ID + 1 ))
done <<EOF
`ls -w 1 /home`
EOF
echo "final : $FILE_ID"

0
1
2
3
4
5
final : 6

Comment se fait-il que dans le 1er cas la valeur de la variable FILE_ID ne survive pas au dela de la boucle while ?!

Merci pour vos éclairages !

[disedorgue]

Bonjour,

Dans le premier cas, tu passes par un sous shell suite au pipe, c'est la cause de la perte de tes variables dans ta boucle while.

[gRRosminet]

Merci.

Et y a-t-il un moyen de ne pas passer dans un sous-shell histoire de conserver un environnement commun entre la boucle et le reste du script ?


Pour info, un collègue me dit qu'il y a 20 ans ça fonctionnait à l'identique dans les 2 exemples et que tout d'un coup a un changement de version ça n'a plus fonctionné (mais ça remonte et il ne sait plus à quel moment ça a basculé)

[Flodelarab]

Et y a-t-il un moyen de ne pas passer dans un sous-shell histoire de conserver un environnement commun entre la boucle et le reste du script ?

Bonjour,

c'est marrant. Pour résoudre le problème de ton premier script, nous donnerions sans doute comme solution ton second script.

Mais prends bien note que tu peux envoyer des tas de choses à ton 'while':

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$ while read ligne; do ...; done < fichier
$ while read ligne; do ...; done < <(ls -w 1 /home)
$ while read ligne; do ...; done <<EOF
blabla
EOF
$ while read ligne; do ...; done <<< $ma_variable
$ while read ligne; do ...; done < mon_pipe_nomme

[gRRosminet]

Merci pour vos reponses. Je ne connaissais pas la 2eme avec la commande entre parenthèses.

[Flodelarab]

On appelle cela une substitution de commande.

[N_BaH]

Bonjour,

dans le premier cas, le pipe (|) crée un sous-interpréteur en dehors duquel les variables qui y sont créées n'existent pas.
le deuxième cas, lit un flux venant d'un document en ligne, ça pourrait être celui d'une redirection d'un fichier.

ON N'UTILISE PAS ls DANS UN SCRIPT !!!

ça fonctionnait à l'identique dans les 2 exemples et que tout d'un coup a un changement de version

quel comportement ? lequel des deux ?
version de quel interpréteur ?

[gRRosminet]

ON N'UTILISE PAS ls DANS UN SCRIPT !!!

Ce n'est pas le sujet de la question, d'autant plus que la ça me sert juste générer l'itération, mais je suis curieux ... pourquoi pas de ls dans un script ?

[N_BaH]

à cause de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
fichier avec des espaces
fichier\
avec\
alinea

...

[gRRosminet]

il y a 20 ans ça fonctionnait à l'identique dans les 2 exemples et que tout d'un coup a un changement de version ça n'a plus fonctionné

quel comportement ? lequel des deux ?
version de quel interpréteur ?

A l'époque l'environnement était bien conservé à la sortie du while qui lit depuis le pipe.
Quant à l'interpréteur, c'était du bsh, mais la version ....

[jlliagre]

A l'époque l'environnement était bien conservé à la sortie du while qui lit depuis le pipe.
Quant à l'interpréteur, c'était du bsh, mais la version ....

Ce n'était pas du bash qui a toujours eu ce comportement horripilant mais ksh qui place la dernière partie d'un pipe dans le shell courant. Si tu ne veux pas de régressios dans tes scripts, tu peux utiliser ksh.

[N_BaH]

bash a désormais une option lastpipe (à positionner avec shopt) pour exécuter la dernière partie d'un pipe dans l'interpréteur courant.
pour ma part, j'utilise plutôt une redirection d'une substitution de processus.

[jack-ft]

Ce n'était pas du bash qui a toujours eu ce comportement horripilant mais ksh qui place la dernière partie d'un pipe dans le shell courant. Si tu ne veux pas de régressios dans tes scripts, tu peux utiliser ksh.

Mouais...
Je me souviens avoir vérifié que certains ksh utilisent aussi un sous-process dans la dernière partie d'un ksh. :-(
Je ne me souviens plus desquels, peut-être pdksh (ou bien sous solaris, AIX ou HP-UX).

[gRRosminet]

Connaissant bien mon collègue il a une très forte tendance à toujours utiliser bsh.
C'est pas impossible que le bsh ait changé de mode de fonctionnement à un moment donné. Cela dit, toutes les machines ou je viens d'essayer avec du ksh transmettent bien l'environnement

[jlliagre]

Mouais...
Je me souviens avoir vérifié que certains ksh utilisent aussi un sous-process dans la dernière partie d'un ksh. :-(
Je ne me souviens plus desquels, peut-être pdksh (ou bien sous solaris, AIX ou HP-UX).

Je faisait référence aux versions de ksh issues du code écrit par David Korn, ksh88 et ksh93, celles que l'on retrouve en particulier sous les Unix que tu cites, mais qui est aussi disponible sur Linux depuis pas mal d'années maintenant que ksh93 est open source.

En revanche, je ne faisait pas référence à pdksh qui n'est pas un "vrai" ksh, juste une réimplémentation limitée et qui en effet a un comportement identique à bash pour ce qui concerne les pipelines.

Connaissant bien mon collègue il a une très forte tendance à toujours utiliser bsh.
C'est pas impossible que le bsh ait changé de mode de fonctionnement à un moment donné. Cela dit, toutes les machines ou je viens d'essayer avec du ksh transmettent bien l'environnement

Je croyais à une faute de frappe pour "bash" quand j'ai lu "bsh". Ton collègue utilise-t-il AIX où bsh est le bourne shell original (celui de Steve Bourne) ?

Si c'est le cas, je doute qu'une version du Bourne shell ait pu placer les fins de pipelines dans le shell courant. Ça aurait introduit une incompatibilité avec les scripts existants, ce que les éditeurs d'OS essaient d'éviter lorsque c'est possible.