On 11/05/2012 15:58, marc.terrier@??? wrote:
> Bonjour à tous,
>
> Hier, j'ai été amené, dans le cadre de mon travail, à essayer de trouver pourquoi un certain script KSH ne se comportait pas comme on aurait voulu. Au final, j'ai réussi à localiser le problème, et à le contourner, mais pas à *expliquer* le pourquoi du comment.
>
> Le soir, chez moi, j'ai même pris 5 mn pour essayer de reproduire le problème sur une machine perso, mais sans y parvenir, parce que chez moi, le comportement obtenu était bien celui auquel je m'attendais. Alors si l'un ou l'une d'entre vous voit une erreur grossière, ci-dessous, qui pourrait expliquer le mystère, je suis preneur...
>
> Je ne reproduis ci-dessous que la partie de script qui pose problème. Je précise que je ne suis pas l'auteur initial de ce script. En particulier, je ne comprends pas :-) pourquoi la personne qui a programmé ça, à l'origine, fait une *boucle* pour lire la seule et unique ligne du fichier de configuration, alors que quelques lignes plus haut (non reproduites ici), le script vérifie que ce fichier de configuration ne comporte qu'une et une seule ligne, et s'arrête si ce n'est pas le cas... Hum !
>
> 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
>
> À l'origine, le script ne comportait que les lignes qui sont ici numérotées de 04 à 05, et 07 à 12, et le case/esac qui commence ligne 17. C'est moi qui ai rajouté les lignes 01, 02, 06, 14 et 15. La ligne 14 résoud le problème en annulant l'effet de la boucle qui précède, mais ça n'explique pas pourquoi la variable $VARIABLE perd sa valeur à la sortie de la boucle while ... do ... done.
>
> Voici les traces d'exécution au boulot, sur une machine RHEL 5.5 (quand la ligne 14 est en commentaires), avec un fichier de configuration qui ne contient qu'un Y majuscule :
>
> DEBUG1> ${VARIABLE}='tata'
> DEBUG2> ${VARIABLE}='Y'
> DEBUG3> ${VARIABLE}='' la variable perd sa valeur reçue précédemment, comme si elle avait une portée limitée au while do done ???
>
> Et voici les traces d'exécution chez moi, sous Ubuntu 10.04 LTS (quand la ligne 14 est en commentaires) :
>
> DEBUG1> ${VARIABLE}='tata'
> DEBUG2> ${VARIABLE}='Y'
> DEBUG3> ${VARIABLE}='Y'
>
> On a constaté le problème en remarquant que, dans le case/esac, on passait toujours dans le cas par défaut *). Or les lignes 06 et 15, rajoutées par mes soins, montrent que $VARIABLE perd sa valeur une fois qu'on sort de la boucle while.
>
> La ligne 14 a été rajoutée après coup pour contourner le problème, sans le dièse de commentaire, bien sûr. Cela règle le problème, mais ne l'explique pas. Une idée, quelqu'un ?
>
> Merci d'avance.
>
>
avec Bash, le résultat :
DEBUG1> ${VARIABLE}='tata'
DEBUG2> ${VARIABLE}='Y'
DEBUG3> ${VARIABLE}='tata'
la variable issue du fichier là aussi n'a une portée que dans le while
par contre ici bash conserve la variable externe au subshell
que donne ceci sous ton ksh :
VARIABLE="tata"
while read line ; do
VARIABLE=$line
done < <( cat ${REP_SOURCE}/FichierDeConfiguration.txt )
echo $VARIABLE
qui devrait normalement te sortir la variable issue de la config
HTH
--
Marc BERLIOUX
Le gouvernement a un bras long et un bras court:
le long sert à prendre et arrive partout ; le bras court sert à donner
mais il arrive seulement à ceux qui sont tous près.
