Comprendre if &&

Bonjour

Je me trouve confronter à problème de syntaxe/incompréhension. le code ci-dessous fonctionne mais pas exactement comme je le veux. Dans la déclaration du if, je cherche a faire un &&. Cela marche mais le shell fait comme si "&& $i != $expr" était quelque chose a éxéctuer et me retourne un message du type : valeur de $i : Permission denied ...

A ce stade, $i est un chemin. Je veux simplement qu'il vérifie si $i est différents de $expr. Mais il m'écoute pas, il fait ce que je lui dit, pas ce que je veux ... ^^

Quelqu'un pourrait m'aider à comprendre cette $$@#! de syntaxe ?

Code:

---

1 2 3 4 5 6 7 8

if ( ! echo ${tab_exeption[*]} | grep -q $i && $i != $expr ) ; then gpg --verify $i $strmod"Release" &>/dev/null if [ $? != 0 ] ; then error=1 tab_error[$vartab]=$i ((vartab++)) fi fi

---

Il y a plein de façon de faire, en voilà une :

Code:

---

if ( ! echo ${tab_exeption[*]} | grep -q $i && [ $i != $expr ] )

---

Citation:

---

Envoyé par matafan

Il y a plein de façon de faire, en voilà une :

Code:

---

if ( ! echo ${tab_exeption[*]} | grep -q $i && [ $i != $expr ] )

---

---

Merci,

Mais pourrais-tu m'expliquer ce qui colle pas dans mon truc ?

De plus, maintenant je me rend compte qu'en fait mon code ne fonctionne pas.

En toute logique, je voudrais m'assurer que $i ne commence pas par /home. De fait, j'ai initialisé la variable expr à : ^/home/ . Et bien évidemment, ca ne fonctionne pas !

Bon en tout cas, la modif proposé fonctionne, c'est déjà une erreur de moins !

Merci

Code:

---

( ! echo ${tab_exeption[*]} | grep -q $i && [[ $i =~ $expr ]] )

---

A réglé mon problème de regex.

Citation:

---

Envoyé par Nelmo

Merci,
Mais pourrais-tu m'expliquer ce qui colle pas dans mon truc ?

---

Bonjour,
dans la ligne que tu as indiquée:

Code:

---

1 2 3

if ( ! echo ${tab_exeption[*]} | grep -q $i && $i != $expr ) ; then blabla fi

---

Les parenthèses ne servent à rien: elles ne font que générer un sous-shell inutile. Ce code est donc équivalent à quelque chose comme:

Code:

---

1 2 3

if cmd1 && $i != $expr ; then blabla fi

---

Le shell, lisant de gauche à droite, exécute cmd1 puis, si le résultat est vrai (ou $? == 0), il exécute la suite qui est $i != $expr. Il expanse $i puis considère son résultat comme le nom d'une commande à exécuter, ce qui n'est évidemment pas ce que tu souhaites, et va te sortir un joli message d'erreur, par exemple, si le contenu de $i est "coucou":

Code:

---

ksh: coucou: not found.

---

Manifestement, tu voudrais tester si $i est différent de $expr. Pour cela, il faut exécuter un programme de test, par exemple la commande interne du shell test, soit:

Code:

---

1 2 3

if cmd1 && test $i != $expr ; then blabla fi

---

qui va faire ce que tu voulais.

Il existe une autre commande de test. C'est la commande interne du shell [:

et qui, à ma connaissance, ne fait guère plus que d'appeler test, soit:

Code:

---

1 2 3

if cmd1 && [ $i != $expr ]; then blabla fi

---

Du coup, on comprend aussi pour quoi il faut absolument une espace avant et après [. Sinon il cherche la commande [$i.

Ces 2 commandes ont leur équivalent en programme externe ici:

Code:

---

1 2 3

$ ls -l '/usr/bin/[' /usr/bin/test -rwxr-xr-x 1 root root 30064 Oct 30 2008 /usr/bin/test* -rwxr-xr-x 1 root root 32296 Oct 30 2008 /usr/bin/[*

---

Une autre possibilité est d'utiliser une autre fonction de comparaison interne au shell:

Code:

---

1 2 3

if cmd1 && [[ $i != $expr ]]; then blabla fi

---

Voilà.
HTH
)jack(

Bonjour,

Citation:

---

Envoyé par jack-ft

Une autre possibilité est d'utiliser la fonction de comparaison interne au shell:

---

test et [ sont aussi des commandes internes du shell !
Il y a de nombreuses commandes internes du shell qui ont leur homonyme sous /bin/.
Si on n'utilise pas les propriétés avancées de [[, autant utiliser test, ou [.

Citation:

---

Envoyé par N_BaH

Bonjour,

test et [ sont aussi des commandes internes du shell !
Il y a de nombreuses commandes internes du shell qui ont leur homonyme sous /bin/.
Si on n'utilise pas les propriétés avancées de [[, autant utiliser test, ou [.

---

Bonjour,
je viens de vérifier et j'apprends(!) je confirme que test et [ sont aussi des commandes internes du shell !

Pour tester "test", il suffit par exemple de faire:

Code:

---

1 2 3 4 5 6

$ echo "echo coucou" > ./test $ chmod +x ./test $ PATH=.:$PATH $ test 3 = 4 $ echo $? 1

---

Du coup, je vais corriger mon précédent post pour éviter de laisser des informations erronées qui pourraient enduire d'erreur les lecteurs potentiels!

Par ailleurs, le livre "Le KornShell" de Bolsky et Korn (de 1989-1990), à la page 352, au paragraphe "Caractéristiques obsolètes", indique:
Attention: les caractéristiques suivantes sont actuellement supportées par ksh uniquement dans un but de compatibilité. Leur utilisation est fortement déconseillée. Ces caractéristiques pourront être supprimées dans le futur:
- Les options -k et -t de set.
- echo comme commande intégrée. (utilisez plutôt print).
- test et [ comme commandes intégrées. (utilisez plutôt [[...]]).
- La substitution de commande `...`. (utilisez plutôt $(...)).
- La syntaxe de définition de fonction identificateur(). (utilisez plutôt function identificateur).

Qu'en pensent nos spécialistes?

)jack(

= effectue une comparaison lexicale (tout comme >, et <).
Pour effectuer une comparaison arithmétique (tester si un nombre est égal à un autre, supérieur (ou égal), inférieur (ou égal)), il existe des opérateurs arithmétiques :
-eq égal (equal)
-ne n'est pas égal à (not equal)
-gt strictement supérieur (greater than)
-ge supérieur ou égal (greater or equal)
-lt strictement inférieur (lesser than)
-le inférieur ou égal (lesser or equal)

ou alors on utilise l'évaluation arithmétique entre double parenthèses :

Code:

---

1 2 3 4 5 6

(( nombre1 = nombre2 )) (( nombre1 != nombre2 )) (( nombre1 > nombre2 )) (( nombre1 >= nombre2 )) (( nombre1 < nombre2 )) (( nombre1 <= nombre2 ))

---

le signe dollar des variables n'est pas nécessaire dans ce cas.

Citation:

---

"Le KornShell" de Bolsky et Korn (de 1989-1990)

---

j'en pense que depuis plus de vingt ans après echo et [ sont toujours là.
$( ) a effectivement supplanté ` `
function n'est pas POSIX.

Merci pour vos explications, je lis tout ça et reviens vous.

Edit : Je vous remercie pour ces explications, c'est très intéressant ! Un post que je vais garder dans mes favoris :D

Citation:

---

Envoyé par jack-ft

- echo comme commande intégrée. (utilisez plutôt print).

---

Bonjour
Soit il y a une erreur dans le bouquin, soit la phrase a été mal retranscrite ici car il n'y a aucun rapport entre print (qui est une commande associée à mailcap) et echo. A mon avis, c'est plutôt de printf qu'il parlait...
Maintenant echo est une primitive du shell mais au cas où celle-ci disparaitrait (???), il reste toujours la commande /bin/echo...

Citation:

---

Envoyé par Sve@r

Soit il y a une erreur dans le bouquin, soit la phrase a été mal retranscrite ici car il n'y a aucun rapport entre print (qui est une commande associée à mailcap) et echo. A mon avis, c'est plutôt de printf qu'il parlait...

---

Pas d'erreur car il ne s'agit pas du print de mailcap. C'est ici de la commande interne print de ksh qu'il s'agit. Il vaut mieux utiliser que la commande echo qui pose problème en raison d'implémentations incompatibles entre les différents Unix (à l'origine entre BSD & System V). Cela dit, printf est une meilleure alternative puisque standard.

Citation:

---

Maintenant echo est une primitive du shell mais au cas où celle-ci disparaitrait (???), il reste toujours la commande /bin/echo...

---

Peu de risque qu'echo disparaisse comme primitive shell. Ça n'aurait aucun sens.

Citation:

---

Envoyé par N_BaH

$( ) a effectivement supplanté ` `

---

Les deux syntaxes sont sont toujours supportées mais $( ) est bien sûr préférable.

Citation:

---

function n'est pas POSIX.

---

mais est toujours recommandée dans des scripts ksh car elle présente des caractéristiques nettement plus intéressantes que la syntaxe standard:

• affectation de $0
• support des variables locales
• OPTIND (getopts) spécifique par fonction
• meilleure gestion des traps, signaux, exceptions