Test -n et boucle while

Version imprimable

Bonjour,

Avec man test, je lis :

Code:

1
2
3
4
5
6
7
       -n STRING
              the length of STRING is nonzero
 
       STRING equivalent to -n STRING
 
       -z STRING
              the length of STRING is zero

Donc si je fais -n sur une variable, je peux savoir si elle est non-vide (true) ou vide (false). Or, dans le code suivant, la méthode 2 provoque une boucle infinie que je n'arrive pas à m'expliquer :

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
25
26
27
28
29
30
31
32
33
34
35
36
37
!/bin/bash
 
typeset LISTE="un deux trois quatre cinq"
typeset ITEM=""
typeset -i INDICE=1
 
ITEM=$(echo $LISTE | cut -d' ' -f $INDICE)
 
# METHODE UNE
echo "Methode une"
 
while true
do
        echo "$INDICE = $ITEM"
        let INDICE=$INDICE+1
        ITEM=$(echo $LISTE | cut -d' ' -f $INDICE)
        if [ -z $ITEM ]
        then
                break # Quitter le while true
        fi
done
 
# METHODE DEUX
echo
echo
echo "Methode deux"
 
let INDICE=1
 
ITEM=$(echo $LISTE | cut -d' ' -f $INDICE)
 
while [ -n $ITEM ]
do
        echo "$INDICE = $ITEM"
        let INDICE=$INDICE+1
        ITEM=$(echo $LISTE | cut -d' ' -f $INDICE)
done

Merci d'avance pour vos lumières :ccool:

20/10/2012, 09h36
N_BaH

de l'importance de "quoter" les expressions à tester !

le problème n'existe pas avec les crochets doubles.
20/10/2012, 09h54
Sve@r
Citation:
Envoyé par Bktero

Bonjour,

Avec man test, je lis :

Code:

1 2 3 4 5 6 7 -n STRING the length of STRING is nonzero STRING equivalent to -n STRING -z STRING the length of STRING is zero

Donc si je fais -n sur une variable, je peux savoir si elle est non-vide (true) ou vide (false). Or, dans le code suivant, la méthode 2 provoque une boucle infinie que je n'arrive pas à m'expliquer :
Salut N_Bah t'a fait un résumé. Je vais détailler un peu
Lorsque ITEM est vide, l'instruction test -n $ITEM est traduite en test -n. Or (et ça je ne sais pas si c'est voulu ou si c'est un bug de la commande test) dans ce cas là ça renvoie "vrai". Parce que, comme c'est écrit dans le man, test -n demande une chaine à évaluer et là il n'y en a plus.
Tu auras un problème analogues mais plus explicites si tu écris un truc de ce genre
Code:

1 2 3 4 5 6 while true do echo "Voulez-vous sortir (o/n) ?" read rep test $rep = o && break done
Si tu tapes "return" à la question, tu auras un truc du style "test := unary operator expected" signifiant que le shell, ayant lu test = o avec un seul opérande, demande alors un opérateur unaire et non binaire.

Donc pour pallier ce problème qu'on retrouve à plusieurs niveaux, on encadre toujours les chaines (et les variables stockant des chaines) de quottes doubles
Code:

1 2 3 4 5 6 while true do echo "Voulez-vous sortir (o/n) ?" read rep test "$rep" = "o" && break done
Ainsi, même une chaine vide laissera une présence à gauche de l'opérateur.

Accessoirement encadrer systématiquement les variables de quottes élimine d'autres soucis comme le fait d'avoir des espaces dans la chaine surtout quand la variable est ensuite passée à un outil qui se cale sur l'espace pour travailler comme le "for"...

PS: Les variables sont généralement écrites en minuscules pour ne pas créer de collision avec les variables prédéfinies qui sont, elles, écrites en majuscules...

Après avoir posté, j'ai pensé aux doubles crochets, et j'avais essayé et ça marchait. Bien vu.

Des fois, je trouve le comportement de bash imprévisible. Le script suivant marche très bien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #!/bin/bash typeset LISTE="un deux trois quatre cinq" typeset ITEM="" typeset -i INDICE=1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) let INDICE=1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) while [ $INDICE -le 10 ] do echo "$INDICE = $ITEM" let INDICE=$INDICE+1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) done
C'est le même genre de test pourtant... Toutes les pages que j'ai vu sur le net (quant à while dans bash) utilisent des crochets simples sauf si tests multiples avec && ou ||.

Il y a t-il une documentation précise sur le comportement de [[ ]] face à [ ] ?

EDIT : ah je viens de comprendre ta remarque des quotes : while test -n "$ITEM" marche très bien. Je viens de trouver ce thread où c'est assez bien expliqué pour ceux que ça intéresse.

EDIT 2 : je viens de voir le message de Sve@r ^^
Merci pour les précisions sur les quotes, les conséquences (qui complètent et vont bien bien plus loin que mon lien). Merci aussi pour les noms des variables.

Je vais placer le sujet comme résolu du coup, je pense avoir eu assez d'infos. Merci à tous les deux. :D

Citation:
Envoyé par Bktero
Des fois, je trouve le comportement de bash imprévisible. Le script suivant marche très bien :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 #!/bin/bash typeset LISTE="un deux trois quatre cinq" typeset ITEM="" typeset -i INDICE=1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) let INDICE=1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) while [ $INDICE -le 10 ] do echo "$INDICE = $ITEM" let INDICE=$INDICE+1 ITEM=$(echo $LISTE | cut -d' ' -f $INDICE) done
C'est le même genre de test pourtant...
... pourtant pas tout à fait. Déjà INDICE n'est jamais vide alors que le pb initial venait de la vision qu'avait le shell d'une variable vide...

Citation:

Envoyé par Bktero

Toutes les pages que j'ai vu sur le net (quant à while dans bash) utilisent des crochets simples sauf si tests multiples avec && ou ||.

Attention, && et || ne sont pas des connecteurs internes à test mais des connecteurs du shell. Ils servent donc à connecter des commandes différentes entre elles style rm -f /etc/passwd || echo "effacement impossible" (j'espère que tu bosses pas en root :mouarf:)
Pour les connecteurs internes test faut utiliser "-a" et/ou "-o"
Exemple: année bissextile ou pas
Code:

1 2 year=$(date '+%Y') test $ $(expr $year % 4) -eq 0 -a $(expr $year % 100) -ne 0 $ -o $(expr $year % 400) -eq 0
Accessoirement il n'y a pas d'optimisation de l'évaluation. Donc même si l'évaluation est fixée dès le départ, le test fera toute l'expression
Démo
Code:

1 2 3 rm -f /tmp/a test -d . -o -n "$(touch /tmp/a)" && echo "ok" ls -l /tmp/a
Bien que "." soit un répertoire et que le test soit définitivement vrai dès cet instant, le fichier /tmp/a est quand-même créé...

Citation:

Envoyé par Bktero

Il y a t-il une documentation précise sur le comportement de [[ ]] face à [ ] ?

EDIT : ah je viens de comprendre ta remarque des quotes : while test -n "$ITEM" marche très bien. Je viens de trouver ce thread où c'est assez bien expliqué pour ceux que ça intéresse.

Pendant que tu éditais moi j'ai trouvé celui-là http://abs.traduc.org/abs-5.0-fr/ch07.html#dblbrackets...

22/10/2012, 10h12
jack-ft
Citation:

Envoyé par Sve@r

Attention, && et || ne sont pas des connecteurs internes à test mais des connecteurs du shell.

Justement, c'est bien une source de confusion!
&& et || sont bien des connecteurs internes à [[..]] !!!
(en plus d'être des connecteurs du shell!)

Les commandes suivantes donnent le même résultat:
Code:

1 2 3 4 test 3 -gt 2 && test 4 -gt 3 test 3 -gt 2 -a 4 -gt 3 [ 3 -gt 2 -a 4 -gt 3 ] [[ 3 -gt 2 && 4 -gt 3 ]]
22/10/2012, 19h25
Sve@r
Citation:

Envoyé par jack-ft

Justement, c'est bien une source de confusion!
&& et || sont bien des connecteurs internes à [[..]] !!!
(en plus d'être des connecteurs du shell!)

D'autant plus source de confusion que j'ai l'habitude (de par mon travail sur multiplateformes) d'associer "shell" à "Bourne Shell" alors que là, tu associes "shell" à "bash" (normal vu que c'est le shell par défaut sous Linux)
Citation:
Envoyé par jack-ft

Les commandes suivantes donnent le même résultat:

Code:

1 2 3 4 test 3 -gt 2 && test 4 -gt 3 test 3 -gt 2 -a 4 -gt 3 [ 3 -gt 2 -a 4 -gt 3 ] [[ 3 -gt 2 && 4 -gt 3 ]]
La 3° n'étant qu'un alias de la seconde, et la 4° étant spécifique à bash (que je ne maitrise pas assez), je vais les éliminer des commandes à regarder. Donc voici juste les 2 premières mais rendues systématiquement fausses
Code:

1 2 test 3 -lt 2 && test 4 -lt 3 test 3 -lt 2 -a 4 -lt 3
Hé bien la première n'effectuera qu'une seule comparaison (puisque 2 commandes à suivre mais la seconde n'étant pas exécutée du fait que la première renvoie un état "faux") alors que la seconde fera toute l'évaluation même inutile.
Donc même résultat "visible" mais pas le même résultat au niveau du proc...

Citation:

Envoyé par Sve@r

D'autant plus source de confusion que j'ai l'habitude (de par mon travail sur multiplateformes) d'associer "shell" à "Bourne Shell" alors que là, tu associes "shell" à "bash" (normal vu que c'est le shell par défaut sous Linux)

Attention!
Petite précision: je ne travaille PAS en "bash"!
Bien au contraire, ai-je envie de dire!
J'essaie justement de filtrer, autant que faire se peut, tout ce qui est "bashisme"!
Toutefois, je ne fais pas non plus dans le pur Bourne...

Le petit programme que je maintiens et fais évoluer (environ 51000 lignes, dont 30000 de code) est en Korn shell!
Et il fonctionne dans divers environnements: Linux, AIX, Solaris, HP-UX

Mais tu as complètement raison sur un point: pour plus de précision et de clarté, il serait bon, à chaque fois qu'on propose du code, de préciser si c'est du sh, ksh, bash ou autre!

(il me semble que c'est ce que fait généralement N_BaH (entre autres))
D'ailleurs, j'aimerais bien, un jour, prendre le temps de me renseigner pour comprendre ce fameux terme "POSIX"!!!

En ce qui concerne la 4ème proposition [[ 3 -gt 2 && 4 -gt 3 ]], je suis extrêmement perplexe et j'ai besoin des lumières des spécialistes!

Étant décrit précisément dans mon bouquin de Korn, c'est incontestablement compatible ksh!

Je viens de le tester sur différents sh (le linux pointe vers bash, mais pas l'AIX) et l'instruction semble comprise et donner le résultat attendu!
Citation:
La 3° n'étant qu'un alias de la seconde, et la 4° étant spécifique à bash (que je ne maitrise pas assez), je vais les éliminer des commandes à regarder. Donc voici juste les 2 premières mais rendues systématiquement fausses
Code:

1 2 test 3 -lt 2 && test 4 -lt 3 test 3 -lt 2 -a 4 -lt 3
Hé bien la première n'effectuera qu'une seule comparaison (puisque 2 commandes à suivre mais la seconde n'étant pas exécutée du fait que la première renvoie un état "faux") alors que la seconde fera toute l'évaluation même inutile.
Donc même résultat "visible" mais pas le même résultat au niveau du proc...
Effectivement, on peut "observer" des différences:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ set -u $ echo $ghij ksh: ghij: parameter not set $ test 3 -lt 2 && test 4 -lt $ghij $ echo $? 1 $ test 3 -lt 2 && test 4 -lt $(echo 2 > /tmp/foo; echo 3) $ cat /tmp/foo cat: /tmp/foo: No such file or directory $ test 3 -lt 2 -a 4 -lt $ghij ksh: ghij: parameter not set $ test 3 -lt 2 -a 4 -lt $(echo 2 > /tmp/foo; echo 3) $ cat /tmp/foo 2
Cela dit, je ne sais pas déterminer s'il exécute ou non le 4 -lt 3, c'est-à-dire s'il fait réellement la comparaison?!

23/10/2012, 18h58
Sve@r

Citation:

Envoyé par jack-ft

Attention!
Petite précision: je ne travaille PAS en "bash"!
Bien au contraire, ai-je envie de dire!
J'essaie justement de filtrer, autant que faire se peut, tout ce qui est "bashisme"!
Toutefois, je ne fais pas non plus dans le pur Bourne...

Le petit programme que je maintiens et fais évoluer (environ 51000 lignes, dont 30000 de code) est en Korn shell!
Et il fonctionne dans divers environnements: Linux, AIX, Solaris, HP-UX

Oui, j'ai dit "bash" dans l'optique "shells évolués" (bash, dash, ksh, zsh, ...)

Citation:

Envoyé par jack-ft

D'ailleurs, j'aimerais bien, un jour, prendre le temps de me renseigner pour comprendre ce fameux terme "POSIX"!!!

Il s'agit d'une norme. Tu dois savoir que Unix a été développé dans les années 80 de façon parallèle par 2 grands consortiums
1) at&t (équivalent de France Telecom) qui a donné Unix system V
2) l'université de Berkeley qui a donné Unix bsd
Chacun ayant sa propre conception de certains concepts. L'un développa la commande "more" tandis que l'autre développait "pg". L'un décida que ls -n afficherait le uid/gid des fichiers alors que ce serait ls -N dans l'autre etc etc.

Donc un jour pour éviter un ratage total il fallut établir une norme disant par exemple que "-h" serait systématiquement l'option associée à l'help. L'ensemble de cette norme se nomme "posix"...

Citation:

Envoyé par jack-ft

Cela dit, je ne sais pas déterminer s'il exécute ou non le 4 -lt 3, c'est-à-dire s'il fait réellement la comparaison?!

On peut le présumer vu qu'il exécute le touch...
24/10/2012, 12h58
jack-ft
Citation:

Envoyé par Sve@r

Oui, j'ai dit "bash" dans l'optique "shells évolués" (bash, dash, ksh, zsh, ...)

Ok

Citation:

Il s'agit d'une norme. Tu dois savoir que Unix a été développé dans les années 80 de façon parallèle par 2 grands consortiums
1) at&t (équivalent de France Telecom) qui a donné Unix system V
2) l'université de Berkeley qui a donné Unix bsd
Chacun ayant sa propre conception de certains concepts. L'un développa la commande "more" tandis que l'autre développait "pg". L'un décida que ls -n afficherait le uid/gid des fichiers alors que ce serait ls -N dans l'autre etc etc.

Donc un jour pour éviter un ratage total il fallut établir une norme disant par exemple que "-h" serait systématiquement l'option associée à l'help. L'ensemble de cette norme se nomme "posix"...

Merci pour cette définition

Effectivement, j'ai commencé à bosser en 83 sur une SM90 sous SMX ou SOL, puis sous Multics, et sur VAX/UNIX en 84. Et je crois bien que c'était de la BSD 4.1 puis 4.2. Puis un peu de Sun/SunView et j'ai connu l'arrivée de X-window et un peu de NeXT/nextstep.

La principale différence que je voyais, c'était pour 'ps -edf' vs 'ps -agxlw' et souvent je faisais un alias de ps vers /usr/ucb/ps par exemple.

Citation:

On peut le présumer vu qu'il exécute le touch...

Je ne le jurerais pas!
Je ne connais pas très bien le mécanisme d'interprétation du shell (ça semble plus compliqué qu'en lisp!), mais il semble bien que l'expansion des arguments se fasse avant l'appel de la fonction, ce qui permet d'écrire des tests où l'opérateur est dynamique comme:
Code:

1 2 $ OP=-lt ; test 3 $OP 4 ; echo $? 0
Même le nombre d'arguments peut être statiquement indéterminé !
Code:

1 2 3 4 5 $ OPA='-lt 4' ; test 3 $OPA ; echo $? 0 $ test 3 -lt $(print "2 -a 4 -lt 5") ; echo $? 1
Je suppose donc que l'interpréteur a besoin d'évaluer les arguments AVANT de commencer à faire les tests, c'est-à-dire qu'il transforme test 3 -lt $(print "2 -a 4 -lt 5") en test 3 -lt 2 -a 4 -lt 5 avant de rentrer dans le code de "test" proprement dit qui consiste à faire l'analyse lexicosyntaxique des arguments, laquelle échoue avant les tests:
Code:

1 2 $ test 3 -lt 2 -a 2 -lt ksh: test: -lt: missing second argument
puis à faire la première comparaison 3 -lt 2 qui, échouant, ne nécessite pas la 2ème.

Bon, le plus simple et surtout le plus sûr, ce serait de regarder les specs (s'il y en a) ou à défaut, le code!

Rq: la commande intégrée [[...]] ne semble pas fonctionner de la même manière
Code:

1 2 3 4 5 $ OP=-lt $ [ 3 $OP 4 ] ; echo $? 0 $ [[ 3 $OP 4 ]] ; echo $? ksh: syntax error: `3' missing expression operator