Discussion :

[jack-ft]

Bon, la dernière fois, j'avais un souci avec le ksh d'AIX; maintenant, c'est avec celui de HP-UX :-(

Contrairement à linux, le ksh d'HP-UX semble ne pas reconnaître le bang ('!') devant une expression...

sous Linux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
$ true
$ echo $?
0
$ ! true  
$ echo $?
1

Jusque là, tout va bien...

Sous HP-UX:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
% uname -a
HP-UX ppaleml B.11.11 U 9000/800 2323570091 unlimited-user license
$ true
$ echo $?
0
$ ! true  
ksh: !:  not found

Y a-t-il un autre moyen que de réécrire tous mes tests pour les passer sous UP-UX?

Par exemple, dois-je convertir (avec une bonne vieille macro emacs) mes tests:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ! fgrep -q 'blabla' file ; then blabla ; fi

en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if fgrep -q 'blabla' file ; [[ $? -eq 0 ]] ; then blabla ; fi

En fait, en regardant la doc de plus près, il semblerait que le bang soit plutôt destiné à nier une expression-du-test, lorsque celle-ci est entre double crochets:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if [[ ! "x$a" = "x$b" ]] ; then ... fi

même si l'écriture suivante fonctionne aussi sous linux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ! [[ "x$a" = "x$b" ]] ; then ... fi

Quelle est votre expérience sur ce phénomène?

Merci d'avance

)jack(

[frp31]

"!" n'est pas une fonction standard c'est donc normal de ne pas la trouver systématiquement sur tous les interpreteurs ksh.

[Sve@r]

Par exemple, dois-je convertir (avec une bonne vieille macro emacs) mes tests:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ! fgrep -q 'blabla' file ; then blabla ; fi

en

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if fgrep -q 'blabla' file ; [[ $? -eq 0 ]] ; then blabla ; fi

Salut

D'un point de vue lisibilité pure, mettre "if grep" alors que le if s'applique en réalité à l'évaluation $? -eq 0 est déroutant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if [[ $? -eq 0 ]] ; then blabla ; fi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if fgrep -q 'blabla' file ; then true; else blabla ; fi

En fait, en regardant la doc de plus près, il semblerait que le bang soit plutôt destiné à nier une expression-du-test, lorsque celle-ci est entre double crochets:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if [[ ! "x$a" = "x$b" ]] ; then ... fi

même si l'écriture suivante fonctionne aussi sous linux:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if ! [[ "x$a" = "x$b" ]] ; then ... fi

Quelle est votre expérience sur ce phénomène?

Plutôt inutile de nier un test alors qu'il possède tous les outils pour inverser l'opérateur de comparaison
Et mettre "x" dans les deux expressions est inutile vu qu'elles sont entre guillemets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if [ "$a" != "$b" ] ; then ... fi

[Jean.Cri1]

Personnellement j'aime bien la syntaxe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 ma commande
[[ $? != 0 ]]\
             && { instructions gestion erreur ;} \
             || { intructions pour succes mais plutot ecrites dans la suite du programme ;}

NB : a mon avis ce post devrait se trouver dans la section unix

[jack-ft]

Bonjour,

Personnellement j'aime bien la syntaxe suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 ma commande
[[ $? != 0 ]]\
             && { instructions gestion erreur ;} \
             || { intructions pour succes mais plutot ecrites dans la suite du programme ;}

J'avoue que j'ai du mal à lire cette façon d'écrire. Avec un bon "if then elif else", je comprends tout de suite ce qui a été écrit (que ce soit par moi ou par un autre (ce qui est fréquemment le cas dans mon métier)).
Pour moi, j'ai plutôt tendance à réserver le '&&' et le '||' pour combiner des valeurs logiques et non comme structure de contrôle. C'est comme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(and (test1) (action1))
(or (test2) (action2))

Je préfère nettement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(when (test1) (action1))
(when (not (test2)) (action2))

C'est beaucoup plus facile à lire pour moi et j'attends du compilateur qu'il le traite avec la même efficacité!

NB : a mon avis ce post devrait se trouver dans la section unix

Pour moi, il s'agit vraiment de spécificités et/ou de syntaxe du ksh, qui varie d'un OS (ou d'une implémentation) à l'autre, non?

)jack(

[jack-ft]

Salut

D'un point de vue lisibilité pure, mettre "if grep" alors que le if s'applique en réalité à l'évaluation $? -eq 0 est déroutant

C'est amusant que ce soit déroutant pour toi, alors que, pour moi, c'est l'inverse!
Si j'ai une fonction dont la nature est d'être un prédicat, c'est-à-dire qu'elle fait un test (sans effet de bord) et retourne un booléen, je m'attends a priori à pouvoir l'utiliser dans la clause conditionnelle d'un "if".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if [[ $? -eq 0 ]] ; then blabla ; fi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if fgrep -q 'blabla' file ; then true; else blabla ; fi

Je trouve très étrange d'écrire une instruction de test, puis, de manière asynchrone et via une variable spéciale, de tester la valeur qui a été "retournée".
De plus, si on n'utilise pas les doubles crochets, on a un problème méta-circulaire, car

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if [ $? -eq 0 ] ; then blabla ; fi

est équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if test $? -eq 0 ; then blabla ; fi

lequel, si on suit la même logique, pourrait/devrait être écrit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; test $? -eq 0 ; if [ $? -eq 0 ]; then blabla ; fi

c'est-à-dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; test $? -eq 0 ; test $? -eq 0 ; if [ $? -eq 0 ]; then blabla ; fi

si on veut s'arrêter un jour, il faut soit utiliser une spécificité du if (les doubles crochets), soit admettre que "if" peut tester le code de retour de la commande test (/usr/bin/test) et donc de n'importe quelle autre commande comme fgrep ou ls ou autre.

A priori, quand je programme, je m'attends à ce que la valeur de retour d'un prédicat soit dans la pile d'appel et non dans une variable spéciale!
De plus, cela oblige à savoir que 0 est la valeur vraie (ce qui est assez contraire à l'habitude prise en mathématiques!), alors que l'appel imbriqué permet justement de se passer de ça.
Peut-être est-ce une déformation due à plus de 25 ans de programmation fonctionnelle...

Plutôt inutile de nier un test alors qu'il possède tous les outils pour inverser l'opérateur de comparaison

Ben justement non! Il n'y a pas tous les outils pour inverser un test puisqu'il manque précisément le "!"!!!
Par exemple, j'ai un bout de code qui fait (ou faisait):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    if ! _REQ_findRequirementsFile ; then
        _REQ_logInfo "No requirements to check"
        return ${REQ_TRUE}
    elif ! _REQ_checkMetaRequirements ; then
        _REQ_logEnvironmentError "Unable to check the requirements"
        return ${REQ_FALSE}
    elif _REQ_checkRequirements ; then
        _REQ_logInfo "All requirements are met for ${REQ_NAME}."
        _REQ_logInfo - "${dash}"
        return ${REQ_TRUE}
    else
        logger_warn "REQ - Some requirements are unmet for ${REQ_NAME}."
        _REQ_logInfo - "${dash}"
        return ${REQ_FALSE}
    fi

Je fais une série de tests et retourne en fonction des résultats.
Personnellement, je n'ai pas de mal à (re)lire et comprendre ce bout de code.
Et ce n'est pas très commode de se passer du "!" dans ce genre de code car, du coup, il faut séparer les appels des prédicats du test de leur valeur de retour, ce qui fait que le code est de plus en plus indenté au fur et à mesure des tests. Beurk!
Bon, c'est vrai que, dans ce cas précis, compte-tenu du "return" dans chaque clause, on pourrait faire plusieurs "if" et fermer par un "fi" après chaque "return".

Et mettre "x" dans les deux expressions est inutile vu qu'elles sont entre guillemets

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if [ "$a" != "$b" ] ; then ... fi

J'ai cru pendant longtemps que les mettre entre guillemets suffisait (notamment pour le traitement des chaînes vides ou contenant des espaces), mais j'ai vu des cas où le test plantait à cause d'une variable contenant une chaîne commençant par un tiret et où le shell n'y retrouvait plus ses petits! Depuis, je me méfie (c'est qu'on nous demande de la robustesse!).

Cela dit, merci quand même pour tes réponses. Je vais réécrire mon code en me passant du bang!

)jack(

[Sve@r]

De plus, si on n'utilise pas les doubles crochets, on a un problème méta-circulaire, car

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if [ $? -eq 0 ] ; then blabla ; fi

est équivalent à:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; if test $? -eq 0 ; then blabla ; fi

lequel, si on suit la même logique, pourrait/devrait être écrit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; test $? -eq 0 ; if [ $? -eq 0 ]; then blabla ; fi

c'est-à-dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

fgrep -q 'blabla' file ; test $? -eq 0 ; test $? -eq 0 ; if [ $? -eq 0 ]; then blabla ; fi

si on veut s'arrêter un jour, il faut soit utiliser une spécificité du if (les doubles crochets), soit admettre que "if" peut tester le code de retour de la commande test (/usr/bin/test) et donc de n'importe quelle autre commande comme fgrep ou ls ou autre.

Tout à fait. Mais en Bourne Shell (le tout premier) si une instruction if ls est possible, l'inverse if ! ls ne l'est pas.
D'où une écriture un peu plus carrée (oserais-je dire "scolaire" ?) qui est de 1) exécuter la commande 2) vérifier son code d'état ce qui permet d'inverser facilement le 2

Et on peut même renforcer la robustesse en capturant le code d'état ce qui permet d'insérer des echo de debug intermédiaire

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ls ...; status=$?
echo "Résultat ls: $status"
if test $status -eq/-ne 0
then
    ...
else
    ...
fi

Ben justement non! Il n'y a pas tous les outils pour inverser un test puisqu'il manque précisément le "!"!!!
Par exemple, j'ai un bout de code qui fait (ou faisait):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    if ! _REQ_findRequirementsFile ; then
        _REQ_logInfo "No requirements to check"
        return ${REQ_TRUE}
    elif ! _REQ_checkMetaRequirements ; then
        _REQ_logEnvironmentError "Unable to check the requirements"
        return ${REQ_FALSE}
    elif _REQ_checkRequirements ; then
        _REQ_logInfo "All requirements are met for ${REQ_NAME}."
        _REQ_logInfo - "${dash}"
        return ${REQ_TRUE}
    else
        logger_warn "REQ - Some requirements are unmet for ${REQ_NAME}."
        _REQ_logInfo - "${dash}"
        return ${REQ_FALSE}
    fi

Tu as donné un exemple très facile car bardé de return. Autrement dit, on peut même éviter tous les else (et réussir quand-même le travail sans passer par ! )

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
_REQ_findRequirementsFile ; if test $? -ne 0 ; then
	_REQ_logInfo "No requirements to check"
	return ${REQ_TRUE}
fi
_REQ_checkMetaRequirements ; if test $? -ne 0; then
	_REQ_logEnvironmentError "Unable to check the requirements"
	return ${REQ_FALSE}
fi
_REQ_checkRequirements ; if test $? -ne 0 ; then
	_REQ_logInfo "All requirements are met for ${REQ_NAME}."
	_REQ_logInfo - "${dash}"
	return ${REQ_TRUE}
fi
logger_warn "REQ - Some requirements are unmet for ${REQ_NAME}."
_REQ_logInfo - "${dash}"
return ${REQ_FALSE}

Toutefois je parlais d'outil pour inverses les opérateurs de la commande spécifique "test" et non d'outil pour inverser une alternative basée sur d'autres commandes...
Exemple: test année bissextile puis test année non bissextile

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
y=`date '+%Y'`
test \( `expr $y % 4` –eq 0 –a `expr $y % 100` –ne 0 \) –o `expr $y % 400` -eq 0
test \( `expr $y % 4` –ne 0 –o `expr $y % 100` –eq 0 \) –a `expr $y % 400` -ne 0

Bien entendu il faut aussi être à l'aise avec les lois mathématiques de De Morgan...

mais j'ai vu des cas où le test plantait à cause d'une variable contenant une chaîne commençant par un tiret et où le shell n'y retrouvait plus ses petits

Je n'avais jamais songé à cette possibilité (à laquelle je n'ai jamais été confronté). Mais je viens de tester

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=-x
b=-y
test $a = $b || echo ok
test "$a" != "$b" && echo ok

et les deux tests ont fonctionné...

[jack-ft]

Tout à fait. Mais en Bourne Shell (le tout premier) si une instruction if ls est possible, l'inverse if ! ls ne l'est pas.

C'est bien ce que je lui reproche!

D'où une écriture un peu plus carrée (oserais-je dire "scolaire" ?) qui est de 1) exécuter la commande 2) vérifier son code d'état ce qui permet d'inverser facilement le 2

C'est effectivement la conséquence logique et qui permet d'avoir une écriture symétrique!

Et on peut même renforcer la robustesse en capturant le code d'état ce qui permet d'insérer des echo de debug intermédiaire

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
ls ...; status=$?
echo "Résultat ls: $status"
if test $status -eq/-ne 0
then
    ...
else
    ...
fi

J'ai effectivement aussi été échaudé par le 'test $? -eq 0' où le $? "change" si on insère une instruction de debug, ce qui n'est pas possible avec l'écriture directe que je préfère. Du coup, systématiquement et comme tu le préconises, je stocke le code retour dans une variable, ce qui fait une variable de plus...

Tiens, au passage, avez-vous testé ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
typeset out=$(echo glop | fgrep glop); echo $?
0
typeset out=$(echo glop | fgrep pasglop); echo $?
0

:
Amusant, non?

Tu as donné un exemple très facile car bardé de return.

Oui, oui, c'est bien ce que j'avais dit: "compte-tenu du "return" dans chaque clause...", mais ce n'est pas toujours le cas...

Je n'avais jamais songé à cette possibilité (à laquelle je n'ai jamais été confronté). Mais je viens de tester

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a=-x
b=-y
test $a = $b || echo ok
test "$a" != "$b" && echo ok

et les deux tests ont fonctionné...

Malheureusement, je ne me souviens plus du cas précis. Voici un exemple un peu capillotracté:

Code sh :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
touch =
a=-f
b=
test $a = $b ; echo $?
0  # Oops!
test "$a" = "$b" ; echo $?
1  # Ouf!

)jack(

[zipe31]

Salut,

Tiens, au passage, avez-vous testé ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
typeset out=$(echo glop | fgrep glop); echo $?
0
typeset out=$(echo glop | fgrep pasglop); echo $?
0

:
Amusant, non?

Ben c'est le code retour de typeset qui est retourné, et non pas celui de "fgrep", donc par conséquent dans les deux cas, comme l'affectation de la variable a réussi, le test est vrai

[Sve@r]

C'est bien ce que je lui reproche!

Arf tu ne peux pas, en toute honnêteté, reprocher au shell de ne pas avoir en lui une évolution qui n'a été amenée que plus tard !!! Ca te manque certes (bien qu'on puisse toujours s'en passer) mais on ne peut pas le reprocher ; on ne peut que le regretter...

Malheureusement, je ne me souviens plus du cas précis. Voici un exemple un peu capillotracté:

Code sh :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
touch =
a=-f
b=
test $a = $b ; echo $?
0  # Oops!
test "$a" = "$b" ; echo $?
1  # Ouf!

En fait je cherchais un exemple où l'utilisation de guillemets ne suffit pas à se prémunir contre les mauvaises interprétations (cf notre première discussion à propos du "x" devant les variables). Là pour l'instant le "x" n'est pas nécessaire...