Portée des variables en ksh [Résolu]

[jack-ft]

Bonjour,

J'ai simplifié mon code à l'extrême pour bien mettre en évidence mon problème (d'où le uuoc).

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#!/bin/ksh
 
function _TTW_test
{
    typeset isOk=0
    echo "1. $$ isOk='${isOk}'"
 
    typeset line
 
    # Check each non empty line of the file
    #egrep -v '^[ \t]*(#|$)' | while read line ; do
 
    cat | while read line ; do
            echo "Check failed for line: '${line}'"
            echo "2a. $$ isOk='${isOk}'"
            isOk=1
            echo "2b. $$ isOk='${isOk}'"
    done
    echo "3. $$ isOk='${isOk}'"
 
    return ${isOk}
}
 
echo "foo\nbar" | _TTW_test

dont le résultat est:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
$ echo $KSH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
 
$ ./test-typeset-while.ksh 
1. 6889 isOk='0'
Check failed for line: 'foo'
2a. 6889 isOk='0'
2b. 6889 isOk='1'
Check failed for line: 'bar'
2a. 6889 isOk='1'
2b. 6889 isOk='1'
3. 6889 isOk='0'

Si je laisse le "cat |" ou si je le remplace par le "egrep" commenté, j'obtiens systématiquement '0' en sortie de boucle au lieu du '1' attendu.

C'est uniquement lorsque je le supprime complètement que j'obtiens '1'.

Quelqu'un peut-il m'expliquer ce qui m'apparaît comme un mystère... à moins que ce ne soit un bug du ksh!

Merci d'avance pour vos explications.

)jack(

[N_BaH]

Bonjour,

ce n'est pas un bug (faut pas rêver ); le pipe (|) ouvre un sous-shell, donc, les variables, qui sont affectées dans le sous-shell, n'existent pas dans le shell parent.

Code :

1
2
3
4
$ echo -e 'foo\nbar\nbaz' | while read line; do [ "$line" = foo ] && maBelleVar="$line"; done; echo "$maBelleVar"

$ echo -e 'foo\nbar\nbaz' | { while read line; do [ "$line" = foo ] && maBelleVar="$line"; done; echo "$maBelleVar";}
foo

[jack-ft]

Envoyé par N_BaH

Bonjour,

ce n'est pas un bug (faut pas rêver ); le pipe (|) ouvre un sous-shell, donc, les variables, qui sont affectées dans le sous-shell, n'existent pas dans le shell parent.

Code :

Merci d'avoir répondu!
Pour un bug, ça me paraissait un peu gros!
C'est bien parce que je soupçonnais quelque chose de ce genre que j'ai pris la précaution d'imprimer le numéro de process $$. Or, comme tu peux le constater dans les traces, il ne varie pas d'un iota (6889 dans l'exemple).
Dois-je en conclure qu'un sous-shell peut avoir le même PID que son père???
Sinon, j'ai contourné le problème à peu près de la même façon que toi (en faisant les grep avant l'appel de la fonction).
)jack(

[Sve@r]

Envoyé par jack-ft

C'est bien parce que je soupçonnais quelque chose de ce genre que j'ai pris la précaution d'imprimer le numéro de process $$. Or, comme tu peux le constater dans les traces, il ne varie pas d'un iota (6889 dans l'exemple).
Dois-je en conclure qu'un sous-shell peut avoir le même PID que son père???

En fait, le terme "sous-shell" ne signifie pas "nouveau processus". Avec le pipe, le shell instancie un nouveau "lui-même" mais reste dans le processus courant.

Exemple

Code bash :

1
2
3
4
5
6
7
#!/bin/sh
i=5
(
    i=6
    echo $i $$
)
echo $i $$

Malgré les parenthèses qui instancient un nouveau contexte (preuve en est que la variable i reste inchangée en fin de parenthèses), le pid ($$) reste le même...

Toutefois ce qui est étonnant c'est que tu es en ksh alors que j'avais remarqué il y a qq années (quand je bossais sous Solaris) que cela ne se produisait pas en ksh

Exemple

Code bash :

1
2
3
4
5
6
7
#!/bin/sh
i=18
cat /etc/passwd |while read line
do
    i=`expr $i + 1`
done
echo $i

Ce code produit un résultat différent en shell (il affiche 18) alors qu'en ksh (sous Solaris) il affiche le nb de lignes du fichier /etc/passwd + 18. Il semblerait qu'en ksh (Solaris), la nouvelle instance conserve les variables

[jack-ft]

pour toutes les réponses.
Je clos
)jack(

[jlliagre]

En fait, si, il s'agit bien d'un "bug" de pdksh dans le sens ou ce dernier ne reproduit pas le comportement du vrai ksh qui place le dernier élément d'un "pipeline"dans le shell courant, contrairement à bash par exemple qui lui choisit le premier.