Comparaison variable avec test "[ ]" ne marche pas

[ggbce]

Salut,

Je suis entrain de faire un petit script bash pour exécuter un backup dans certaines condition (vérifier l'état du tape backup). Je me sert de la dernière ligne de de statut qui donne un resultat en texte, comme par exemple:

Lecteur prêt -> BOT ONLINE IM_REP_EN

Protégé en écriture -> BOT WR_PROT ONLINE IM_REP_EN

Pas de ruban inséré -> DR_OPEN IM_REP_EN

etc...

Je parse le résultat avec sed pour simplement avoir cette ligne que j'ajoute dans une variable $ETAT. Donc pour l'exemple on dira que $ETAT est égal à la chaîne "BOT ONLINE IM_REP_EN" (lecteur prêt).

J'ai ensuite une suite de variables pré-définies avec des valeurs comme:

READY="BOT ONLINE IM_REP_EN"
PROTECTED="BOT WR_PROT ONLINE IM_REP_EN"
VIDE="DR_OPEN IM_REP_EN"

Et finalement de simples boucles if qui font un test sur la valeur des variables comme ceci:

if [ "$ETAT" = "$PROTECTED" ]; then
echo "Protégé en écriture"
exit
fi

if [ "$ETAT" = "$VIDE" ]; then
echo "Pas de ruban dans le lecteur"
exit
fi

if [ "$ETAT" = "$READY" ]; then
echo "Démarrage de la sauvegarde..."
exit
fi

J'ai ajouté les guillemets dans le test, comme spécifié, pour me protégé du shell. J'ai essayé avec les ', ´ ou ` mais ça semble bien le " qui est le bon choix.

Le problème ? c'est qu'il ne fait tout simplement pas le test... il ne comprend pas que la chaîne:

"BOT ONLINE IM_REP_EN" est égale à "BOT ONLINE IM_REP_EN"

Et j'obtiens pas de résultat d'aucun if.

Si je change, pour tester, la valeur des variables avec des chaînes de texte sans espace, comme par exemple:

ETAT="PASBON"

READY="OKCAVA"
PROTECTED="PASBON"
VIDE="CESTVIDE"

if [ "$ETAT" = "$PROTECTED" ]; then
echo "Protégé en écriture"
exit
fi

if [ "$ETAT" = "$VIDE" ]; then
echo "Pas de ruban dans le lecteur"
exit
fi

if [ "$ETAT" = "$READY" ]; then
echo "Démarrage de la sauvegarde..."
exit
fi

Ça marche, j'obtiens: "Protégé en écriture".

-------------------------------------------

Est-ce que quelqu'un peut m'aider ? Je comprends pas pourquoi test [] ne veut pas comparer ( = ) deux chaînes de texte avec des espaces. Si ce n'est pas possible, comment faire ?

Merci

[lorinc]

pourtant, chezmoiçamarche.com ...

[ggbce]

MMMMhhh, je comprends pas trop là....

tu utilises le même genre de formulation ?

TOTO="JE FAIS PAS DE TEST"

A="JE FAIS UN TEST"
B="JE FAIS PAS DE TEST"

if [ "$TOTO" = "$A" ]; then
 echo "Le test donne A"
 exit
fi

if [ "$TOTO" = "$B" ]; then
 echo "Le test donne B"
 exit
fi

En l'occurence le résultat sera: Le test donne B

------------------------

[tuXXX]

TOTO="JE FAIS PAS DE TEST"

A="JE FAIS UN TEST"
B="JE FAIS PAS DE TEST"

if [ "$TOTO" = "$A"]; then
 echo "Le test donne A"
 exit
fi

if [ "$TOTO" = "$B" ]; then
 echo "Le test donne B"
 exit
fi

Il manque un espace entre "$A" et ], mais sinon c'est bon.

En l'occurence le résultat sera: Le test donne B

Donc ça marche

[ggbce]

Désolé de l'erreur dans l'exemple ci-dessus .... mais effectivement j'aurais cru que ça fonctionnait moi aussi.

Vous confirmez que ça fonctionne , donc je ne comprends rien à rien puisque ça ne fonctionne pas sur mon poste. Bon je crois bien que c'est probablement dû à une trop vieille version de ma distribution et que cette fonction ne devait pas bien fonctionner auparavant.

J'essai même un test --version (comme écris dans man) pour connaitre la version et il ne me sort rien. c'Est une vieille Red Hat 7.3 pour ce serveur Web. Je crois que je suis prêt à le migrer en Debian 3.1

[tuXXX]

Désolé de l'erreur dans l'exemple ci-dessus .... mais effectivement j'aurais cru que ça fonctionnait moi aussi.

Tu peux essayer de rajouter "#!/bin/sh" ou "#!/bin/bash" au début pour être sûr d'utiliser sh ou bash, parce que csh ou tcsh ça marche pas forcément pareil...

[ggbce]

#!/bin/bash

est toujours présent dans mes scripts ! Donc ce n'est pas ça le problème.

[tuXXX]

Tu peux essayer avec la commande test aussi...

#!/bin/sh

TEST="$(which test)"

TOTO="JE FAIS PAS DE TEST"

A="JE FAIS UN TEST"
B="JE FAIS PAS DE TEST"

if $TEST "$TOTO" = "$A"
then
 echo "Le test donne A"
 exit
fi

if $TEST "$TOTO" = "$B"
then
 echo "Le test donne B"
 exit
fi

Ça serait étrange d'avoir la commande test qui ne marche pas bien (en revanche, bash qui ne marche pas bien, je trouve ça plus crédible)

[lorinc]

tu ferais pas ça sur un serveur avec un vieux bash tout pourri, par hasard ?

[tuXXX]

c'Est une vieille Red Hat 7.3 pour ce serveur Web.

[lorinc]

C'est quoi la version de bash là-dessus ? RH 7.3 c'est pas trop récent, mais c'est pas totaly outdated non plus... et un problème d'encodage ? genre ta chaine récupérée est en iso-machin et ton scripte en utf-8, ou bien une merdum du genre...

je sais pas, je cherche

[woodystable]

La comparaison de string c'est == en bash, = est une équivalence juste pour être POSIX compilant.

[ggbce]

L'utilisation du == ne change rien malheureusement.

La version de bash qui est avec RH 7.3 est 2.05a-13.

Je sais que ça fait étrange comme problème... puisque même dans les bouquins ils disaient que ça fonctionne cette commande, c'est pour ça que j'ai fais appel à vous

NOTE: Pour m'assurer que le contenu de la variable à comparer est bonne, je fais toujours un echo de la variable et de la chaîne de comparaison à la fin, et le resultat visuel est exactement identique... mais test refuse de l'entendre.

Si par contre, je fais un "test inversé". Je me rends compte que test ne vois pas la même chose dans les 2 variables.

TOTO="JE FAIS PAS DE TEST"

A="JE FAIS UN TEST"
B="JE FAIS PAS DE TEST"

if  [ "$TOTO" = "$A" ]; then
 echo "Le test donne A"
 exit
fi

if [ "$TOTO" != "$B" ]; then
 echo "Le test donne B"
 exit
fi

Dans cet exemple, la réponse sera "Le test donne B". Et il en serait de même si je faisais un != sur $A. Finalement il détecte toujours que c'est différent... même si c'est pareil.

------------------------------

genre ta chaine récupérée est en iso-machin et ton scripte en utf-8, ou bien une merdum du genre...

Qu'est-ce qui me permettrait de déterminer ça ? Ma chaîne est récupéré de la sortie standard avec un sed et mon script est exécuté en tant que root.

Et encore là, comme dans mon exemple, si les valeurs des variables sont donné manuellement directement (ex.: TOTO="JE FAIS UN TEST"), ça fait le même problème.

----------------------------

Tuxxx, placer la commande test dans une variable $TEST pour l'exécuter ne change rien également

[tuXXX]

placer la commande test dans une variable $TEST pour l'exécuter ne change rien également

Dans ce script là, ou dans le tien? Si c'est dans ce script là, en effet y'a un souci plus ou moins inexplicable pour moi. Si c'est dans le tien, alors il faudrait en effet peut-être regarder du côté de l'encoding comme il a été dit.

(Pour l'encoding, un truc simple pour tester c'est de mettre un terminal en iso et en faisant un echo des 2 variable :

echo "[$a]"

echo "[$b]"

à l'oeuil, ça se voit sur des chaînes avec des accents)

[lorinc]

2.05a-13.

c'est fou parce que sur mon server (debian sarge) c'est la même version, et ça marche...

[ggbce]

Ouep,

Je viens de tester le script suivant (qui est à 99% fidèle à mon script réel, car je ne peut pas faire un mt status sur mon portable) sur ma Debian Sarge 3.1 (bash 2.05b) et sur ma Red Hat 7.3 (bash 2.05a-13):

#!/bin/bash

#ETAT=`mt -f /dev/st0 status | sed -nr -e '/IM_REP_EN/ p'`

ETAT="DR_OPEN IM_REP_EN" # Comme si le lecteur serait vide

PROTECTED="BOT WR_PROT ONLINE IM_REP_EN"
PRETOK="BOT ONLINE IM_REP_EN"
NOTREADY="DR_OPEN IM_REP_EN"

if [ "$ETAT" = "$PROTECTED" ]; then
echo "Protégé en écriture"
exit
fi

if [ "$ETAT" = "$NOTREADY" ]; then
echo "Lecteur de bande vide (pas de cassette)"
exit
fi

if [ "$ETAT" = "$PRETOK" ]; then
echo "Prêt pour faire un backup"
exit
fi

echo $ETAT
echo ""
echo $PRETOK
echo $NOTREADY
echo $PROTECTED

Résultats:

La Debian Sarge s'arrête dans le 2e if et se termine avec le résultat "Lecteur de bande vide (pas de cassette)".

La Red Hat 7.3 passe tout droit jusqu'à la fin.

Donc il y a surement un p'tit bug avec RH7.3. Je ne crois pas que le contenu de la variable $ETAT tapé à la main et celui de $NOTREADY, $PRETOK ou $PROTECTED également tapé à la main puissent ne pas utiliser le même encodage ???

[lorinc]

En même temps c'est peut-être la correction entre 2.05a-13 et 2.05b

Faudrait retrouver un changelog de l'époque...

[zoto]

Salut

Regarde du coté de l'encode comme cela ta deja etait suggéré .

Ouvre avec VI .

J'utilise jed et des fois il m'a fait des farces avec des fin de lignes toutes bizarre .

Avec vi j'ai peu m'en appercevoir .

Bon apres vi tous les jour ....

Faut aimer

a+