HP-UX: ksh: !: not found [Résolu]

[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 :

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

Jusque là, tout va bien...

Sous HP-UX:

Code :

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 :

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

en

Code :

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 :

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

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

Code :

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]

Envoyé par jack-ft

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

Code :

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

en

Code :

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 :

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

Code :

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

Envoyé par jack-ft

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 :

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

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

Code :

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 :

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

[Jean.Cri1]

Personnellement j'aime bien la syntaxe suivante :

Code :

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,

Envoyé par Jean.Cri1

Personnellement j'aime bien la syntaxe suivante :

Code :

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 :

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

Je préfère nettement:

Code :

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]

Envoyé par Sve@r

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 :

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

Code :

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 :

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

est équivalent à:

Code :

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

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

Code :

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

c'est-à-dire:

Code :

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 :

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 :

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]

Envoyé par jack-ft

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

Code :

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

est équivalent à:

Code :

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

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

Code :

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

c'est-à-dire:

Code :

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

Envoyé par jack-ft

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 :

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

Envoyé par jack-ft

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 :

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 :

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 :

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...

Envoyé par jack-ft

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 :

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]

Envoyé par Sve@r

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 :

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 :

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 :

et les deux tests ont fonctionné...

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

Code sh :

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,

Envoyé par jack-ft

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

Code :

:
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]

Envoyé par jack-ft

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...

Envoyé par jack-ft

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

Code sh :

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...

[jack-ft]

Envoyé par Sve@r

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...

Tu as farpaitement raison! Je regrette simplement que les concepteurs d'origine n'y aient pas pensé (plus tôt)!

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...

Exact aussi! Dans ce cas, le "x" (sans guillemets) marche aussi bien que les guillemets, mais n'est pas indispensable.

Je ne me souviens plus du tout, mais il est tout à fait possible que ce soit non pas un problème du shell lui-même, mais un problème de "test", c'est-à-dire qu'il ne se produise non pas avec "[[...]]" mais avec "[...]" ou "test ...", et uniquement pour certaines versions de "test" moins "intelligentes" que celle disponible sous linux.

)jack(