Re: Perte de valeur d'une variable dans un script KSH

トップ ページ

このメッセージに返信
著者: Marc TERRIER
日付:  
To: Romain Touzé, ymartin59
CC: guilde
題目: Re: Perte de valeur d'une variable dans un script KSH
Le 11/05/2012 18:18, Romain Touzé a écrit :
> Bonjour,
>
> Le ksh est souvent source de problème j'ai déjà constaté le même
> comportement sur un RHEL.
>
> Première chose, tu n'as pas les mêmes implémentations de ksh sur tous
> les Linux (je pense que le plus souvent, on peut trouver pdksh et
> ksh93). A moins que cela ne vienne de cat ?
>
> Le cat fichier | while read line te fait forker ce qui fait que tu
> perds les modif de VARIABLE.
>
> Je n'ai pas de shell sous la main alors je ne peux pas faire l'essai,
> mais tu pourrais essayer de faire un
>
> while read LINE; do<ton code> done<< FICHIER (un truc du genre)
>
> Mais bon c'est juste par curiosité car j'imagine que tu t'es déjà
> débarrassé de cette horrible boucle !
>
> Ce qu'il faut se rappeler est que ksh N'EST PAS portable.
>
>>
>> 01    VARIABLE="tata"
>> 02    echo "DEBUG1>  \${VARIABLE}='${VARIABLE}'"
>> 03
>> 04    cat ${REP_SOURCE}/FichierDeConfiguration.txt | while read line ; do
>> 05      VARIABLE=$line
>> 06      echo "DEBUG2>  \${VARIABLE}='${VARIABLE}'"
>> 07      if [ $? -ne 0 ] ; then
>> 08        msglog $LOG_FILE 3 3001 "*ERREUR* lors de la récupération du contenu de la ligne $line"
>> 09        msglog $LOG_FILE 3 3001 "*ERREUR* dans le fichier FichierDeConfiguration.txt"
>> 10        f_arretInstall
>> 11      fi
>> 12    done
>> 13
>> 14    #VARIABLE=`cat ${REP_SOURCE}/FichierDeConfiguration.txt`
>> 15    echo "DEBUG3>  \${VARIABLE}='${VARIABLE}'"
>> 16
>> 17    case "${VARIABLE}" in
>> 18      ...
>> 19    esac

>>
>
>
>

Merci à Yves et à Romain pour leurs réponses : personnellement, je ne
voyais pas comment expliquer cette perte de valeur autrement que par un
"contexte" particulier, qui limiterait la portée de la variable, mais je
n'aurais pas cru qu'un simple pipe puisse donner lieu à un tel contexte.
On en apprend tous les jours, et c'est vrai que l'explication que vous
me proposez est très tentante.

C'est d'ailleurs pour ça que j'ai rajouté les lignes 01 et 02 : je
m'attendais à ce que la ligne 15 affiche "tata" (quand la 14 est en
commentaires, bien sûr), comme quand on ressort d'une fonction C/C++ à
laquelle on a passé une variable en paramètre par valeur, non par
adresse, et que la variable globale, même "modifiée" dans la fonction,
retrouve sa valeur initiale dès qu'on sort de la fonction. Mais ça n'a
pas été le cas.

Pour ce qui est de me débarrasser de cette horrible boucle, comme dit
Romain, je l'ai fait, si on veut, en rajoutant la ligne 14, qui annule
l'effet de la boucle, mais je n'ai pas fait plus que ça : en fait, j'ai
été appelé "en pompier" pour dépanner un utilisateur qui voulait juste
lancer un script, et qui n'obtenait pas le résultat décrit dans la
procédure qu'il avait besoin de dérouler. Je ne suis pas censé modifier
ce script, en tout cas pas dans ce cas précis, et d'ailleurs,
l'utilisateur ne m'a accordé que de façon très temporaire l'accès en
écriture.

Donc le fin mot de l'histoire, pour répondre à Yves, c'est que j'ai
finalement enlevé le '#' de commentaire au début de ma ligne 14, une
fois établi que cela résolvait le problème, et j'ai commenté les lignes
02, 06 et 15, pour ne pas polluer les traces habituelles du script avec
mes traces à moi. L'utilisateur s'est estimé content que ça marche mieux
qu'avant, et tout le monde est passé à autre chose : pas trop le temps
pour faire dans la dentelle, et dans l'amélioration de fond.

Encore merci à vous deux. A+

--
Marc TERRIER