Bonjour,
sur une Mandrake 9.2, j'ai un bash 2.05b.
j'ai voulu lancer un script (que j'ai trouvé sur léa-linux) au démarrage
pour charger les iptables, mais il y a une erreur :
./iptables: line 15: [: -eq: unary operator expected
qui se produit sur cette partie :
echo -n "Application des règles IpTables: "
/etc/firewall.sh
RETVAL=?
[ -eq 0 ] && touch /var/lock/subsys/firewall
echo
Pourriez-vous me dire ce qui cloche, je n'ai pas trouvé dans 'man bash' ...
Si RETVAL est censé stocker le code de retour du script /etc/firewall.sh, la ligne est RETVAL=$? et la suivante qui la teste doit être [ $RETVAL -eq 0 ] ...
Mais dans ce cas, pourquoi se casser la tête, autant tester directement: /etc/firewall.sh [ $? -eq 0 ] && touch ...
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui dit ne pas connaître grand chose, alors on explique comment ça fonctionne. En disant, par exemple, que $? contient le dernier code retourné.
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
et encore mieux, le tout sur une seule ligne: /etc/firewall.sh && touch ...
Le but est juste d'utiliser un script déjà écrit, pas de le réécrire.
Cordialement
-- eric bachard
Bonjour,
On Thu, 06 May 2004 18:17:30 +0200, Fauberteau Frédéric wrote:
Si RETVAL est censé stocker le code de retour du script /etc/firewall.sh,
la ligne est RETVAL=$? et la suivante qui la teste doit être
[ $RETVAL -eq 0 ] ...
Mais dans ce cas, pourquoi se casser la tête, autant tester directement:
/etc/firewall.sh
[ $? -eq 0 ] && touch ...
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui dit
ne pas connaître grand chose, alors on explique comment ça fonctionne.
En disant, par exemple, que $? contient le dernier code retourné.
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable
testée est identifiable directement, sans avoir à se taper le contenu du
script qui nous retourne RETVAL.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
et encore mieux, le tout sur une seule ligne:
/etc/firewall.sh && touch ...
Le but est juste d'utiliser un script déjà écrit, pas de le réécrire.
Si RETVAL est censé stocker le code de retour du script /etc/firewall.sh, la ligne est RETVAL=$? et la suivante qui la teste doit être [ $RETVAL -eq 0 ] ...
Mais dans ce cas, pourquoi se casser la tête, autant tester directement: /etc/firewall.sh [ $? -eq 0 ] && touch ...
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui dit ne pas connaître grand chose, alors on explique comment ça fonctionne. En disant, par exemple, que $? contient le dernier code retourné.
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
et encore mieux, le tout sur une seule ligne: /etc/firewall.sh && touch ...
Le but est juste d'utiliser un script déjà écrit, pas de le réécrire.
Cordialement
-- eric bachard
Fauberteau Frédéric
valeur00
echo $valeur
echo ${#valeur}
valeur0
echo ${#valeur} j'avoue que ça permet de comprendre pas mal de chose, ces commandes ...
Merci pour toutes ces explications, je ne verrais plus bash de la même manière ;-)
valeur00
echo $valeur
echo ${#valeur}
valeur0
echo ${#valeur}
j'avoue que ça permet de comprendre pas mal de chose, ces commandes ...
Merci pour toutes ces explications, je ne verrais plus bash de la même
manière ;-)
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test sur du rien [ -eq 0 ].
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui dit ne pas connaître grand chose, alors on explique comment ça fonctionne. En disant, par exemple, que $? contient le dernier code retourné.
man bash et même man sh
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne de caractère "?", pas le code de retour du script /etc/firewall.sh alors que c'est manifestement le but recherché.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Le but est juste d'utiliser un script déjà écrit, pas de le réécrire.
Ben si, puisque la question initiale est de savoir pourquoi le script ne marche pas. Et donc ma proposition script && pose du flag me parait intéressante car 1/ elle marche, 2/ elle est élégante et que c'est une bonne habitude à prendre.
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test
sur du rien [ -eq 0 ].
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui
dit ne pas connaître grand chose, alors on explique comment ça
fonctionne. En disant, par exemple, que $? contient le dernier code
retourné.
man bash et même man sh
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable
testée est identifiable directement, sans avoir à se taper le contenu
du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne
de caractère "?", pas le code de retour du script /etc/firewall.sh alors
que c'est manifestement le but recherché.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un
entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Le but est juste d'utiliser un script déjà écrit, pas de le
réécrire.
Ben si, puisque la question initiale est de savoir pourquoi le script ne
marche pas. Et donc ma proposition script && pose du flag me parait
intéressante car 1/ elle marche, 2/ elle est élégante et que c'est une
bonne habitude à prendre.
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test sur du rien [ -eq 0 ].
Très bonne idée en effet. Mais quand on explique ça à quelqu'un qui dit ne pas connaître grand chose, alors on explique comment ça fonctionne. En disant, par exemple, que $? contient le dernier code retourné.
man bash et même man sh
Dans ce cas
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne de caractère "?", pas le code de retour du script /etc/firewall.sh alors que c'est manifestement le but recherché.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Le but est juste d'utiliser un script déjà écrit, pas de le réécrire.
Ben si, puisque la question initiale est de savoir pourquoi le script ne marche pas. Et donc ma proposition script && pose du flag me parait intéressante car 1/ elle marche, 2/ elle est élégante et que c'est une bonne habitude à prendre.
Tshaw Schott FLLC canal hystérique
Schott
On Sat, 08 May 2004 20:18:18 +0000, Fauberteau Frédéric wrote:
Merci pour toutes ces explications, je ne verrais plus bash de la même manière ;-)
Je me permets de te suggérer man bash. Tu auras une foultitude d'infos aussi intéressantes.
Tshaw Schott FLLC Canal hystérique
On Sat, 08 May 2004 20:18:18 +0000, Fauberteau Frédéric wrote:
Merci pour toutes ces explications, je ne verrais plus bash de la même
manière ;-)
Je me permets de te suggérer man bash. Tu auras une foultitude d'infos
aussi intéressantes.
On Sat, 08 May 2004 20:18:18 +0000, Fauberteau Frédéric wrote:
Merci pour toutes ces explications, je ne verrais plus bash de la même manière ;-)
Je me permets de te suggérer man bash. Tu auras une foultitude d'infos aussi intéressantes.
Tshaw Schott FLLC Canal hystérique
ericb
On Sat, 08 May 2004 18:11:14 +0200, ericb wrote:
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test sur du rien [ -eq 0 ].
Oui, tout le monde l'a vu.
man bash et même man sh
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce n'est que mon humble avis et je vais tenter d'illustrer :
si on cherche une occurrence, dans la page de man de bash, on fait : /occurence +<ENTRÉE> Et la première trouvée apparait surlignée.. n pour "next" c'est à dire l'occurence suivante. Refaire "/" permet d'en chercher une autre, ou flèche haut/bas permet de retrouver l'historique des occurences cherchées.
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne de caractère "?", pas le code de retour du script /etc/firewall.sh alors que c'est manifestement le but recherché.
Nous sommes d'accord là-dessus. Après refléxion, je pense que RETVAL=$? est la solution à ce problème.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Oui, tout à fait -eq ne peut pas attendre une chaine de caractère.
Et donc ma proposition script && pose du flag me parait
intéressante car 1/ elle marche,
Oui elle marche...et [ $RETVAL -eq 0 ] aussi :-)
2/ elle est élégante et que c'est une
bonne habitude à prendre.
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je préfère raisonner en termes de modularité (qui sous entend lisibilité, maintenabilité, portabilité, extensibilité et réutilisabilité). Ici un shell script appelle un autre shell script, et malgré la simplicité de l'exemple qui pourra sembler inadaptée à certains, sur le fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à [ $? -eq 0 ]
Bien sur, cela peut se discuter :-)
Cordialement
-- revp onpuneq
On Sat, 08 May 2004 18:11:14 +0200, ericb wrote:
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test
sur du rien [ -eq 0 ].
Oui, tout le monde l'a vu.
man bash et même man sh
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce
n'est que mon humble avis et je vais tenter d'illustrer :
si on cherche une occurrence, dans la page de man de bash, on fait :
/occurence +<ENTRÉE>
Et la première trouvée apparait surlignée.. n pour "next" c'est à dire
l'occurence suivante. Refaire "/" permet d'en chercher une autre, ou
flèche haut/bas permet de retrouver l'historique des occurences cherchées.
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable
testée est identifiable directement, sans avoir à se taper le contenu
du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne
de caractère "?", pas le code de retour du script /etc/firewall.sh alors
que c'est manifestement le but recherché.
Nous sommes d'accord là-dessus. Après refléxion, je pense que RETVAL=$?
est la solution à ce problème.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un
entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Oui, tout à fait -eq ne peut pas attendre une chaine de caractère.
Et donc ma proposition script && pose du flag me parait
intéressante car 1/ elle marche,
Oui elle marche...et [ $RETVAL -eq 0 ] aussi :-)
2/ elle est élégante et que c'est une
bonne habitude à prendre.
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je
préfère raisonner en termes de modularité (qui sous entend lisibilité,
maintenabilité, portabilité, extensibilité et réutilisabilité).
Ici un shell script appelle un autre shell script, et malgré la
simplicité de l'exemple qui pourra sembler inadaptée à certains, sur le
fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à
[ $? -eq 0 ]
Certes. Mais ces 2 lignes ne peuvent fonctionner, en particulier le test sur du rien [ -eq 0 ].
Oui, tout le monde l'a vu.
man bash et même man sh
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce n'est que mon humble avis et je vais tenter d'illustrer :
si on cherche une occurrence, dans la page de man de bash, on fait : /occurence +<ENTRÉE> Et la première trouvée apparait surlignée.. n pour "next" c'est à dire l'occurence suivante. Refaire "/" permet d'en chercher une autre, ou flèche haut/bas permet de retrouver l'historique des occurences cherchées.
1) l'utilisation de $? est moins lisible que $RETVAL, car la variable testée est identifiable directement, sans avoir à se taper le contenu du script qui nous retourne RETVAL.
Sauf qu'avec la syntaxe utilisée (RETVAL=?), $RETVAL contient la chaîne de caractère "?", pas le code de retour du script /etc/firewall.sh alors que c'est manifestement le but recherché.
Nous sommes d'accord là-dessus. Après refléxion, je pense que RETVAL=$? est la solution à ce problème.
2) Cela ne marche pas si on veut récupérer une chaine de caractères
Si on passe une chaîne de caractère à test pour la comparer à un entier (-eq 0 dans le cas qui nous intéresse), ça ne marchera pas.
Oui, tout à fait -eq ne peut pas attendre une chaine de caractère.
Et donc ma proposition script && pose du flag me parait
intéressante car 1/ elle marche,
Oui elle marche...et [ $RETVAL -eq 0 ] aussi :-)
2/ elle est élégante et que c'est une
bonne habitude à prendre.
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je préfère raisonner en termes de modularité (qui sous entend lisibilité, maintenabilité, portabilité, extensibilité et réutilisabilité). Ici un shell script appelle un autre shell script, et malgré la simplicité de l'exemple qui pourra sembler inadaptée à certains, sur le fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à [ $? -eq 0 ]
Bien sur, cela peut se discuter :-)
Cordialement
-- revp onpuneq
Schott
On Sun, 09 May 2004 00:26:24 +0200, ericb wrote:
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce n'est que mon humble avis et je vais tenter d'illustrer :
Et pourtant... quoi de mieux que de lire la doc?
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je préfère raisonner en termes de modularité (qui sous entend lisibilité, maintenabilité, portabilité, extensibilité et réutilisabilité).
Ben justement. commande1 && commande2 && commande3 améliore à mon sens la lisibilité dans le sens où cela permet de regrouper sur une même ligne une séquences de commandes formant un ensemble logique, une action complète. C'est de plus une syntaxe des plus courantes en shell.
fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à [ $? -eq 0 ]
Je ne suis pas d'accord. D'une part parce que $? n'est pas du tout équivoque, c'est le code de retour de la dernière commande exécutée, d'autre part parce que passe par des variables intermédiaires c'est utiliser plus de mémoire, consommer plus de ressources d'une manière générale. Et c'est une très mauvaise habitude de ne pas économiser ses ressources.
Tshaw Schott Front de Libération de la Ligne de Commande, canal hystérique
On Sun, 09 May 2004 00:26:24 +0200, ericb wrote:
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce
n'est que mon humble avis et je vais tenter d'illustrer :
Et pourtant... quoi de mieux que de lire la doc?
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je
préfère raisonner en termes de modularité (qui sous entend lisibilité,
maintenabilité, portabilité, extensibilité et réutilisabilité).
Ben justement. commande1 && commande2 && commande3 améliore à mon sens
la lisibilité dans le sens où cela permet de regrouper sur une même
ligne une séquences de commandes formant un ensemble logique, une action
complète. C'est de plus une syntaxe des plus courantes en shell.
fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à
[ $? -eq 0 ]
Je ne suis pas d'accord. D'une part parce que $? n'est pas du tout
équivoque, c'est le code de retour de la dernière commande exécutée,
d'autre part parce que passe par des variables intermédiaires c'est
utiliser plus de mémoire, consommer plus de ressources d'une manière
générale. Et c'est une très mauvaise habitude de ne pas économiser ses
ressources.
Tshaw
Schott
Front de Libération de la Ligne de Commande, canal hystérique
Je n'ai jamais trouvé cette réponse "man truc" constructive, mais ce n'est que mon humble avis et je vais tenter d'illustrer :
Et pourtant... quoi de mieux que de lire la doc?
Je ne suis pas tout à fait d'accord. À parler de bonne habitude, je préfère raisonner en termes de modularité (qui sous entend lisibilité, maintenabilité, portabilité, extensibilité et réutilisabilité).
Ben justement. commande1 && commande2 && commande3 améliore à mon sens la lisibilité dans le sens où cela permet de regrouper sur une même ligne une séquences de commandes formant un ensemble logique, une action complète. C'est de plus une syntaxe des plus courantes en shell.
fond, je pense que l'utilisation de [ $RETVAL -eq 0 ] est préférable à [ $? -eq 0 ]
Je ne suis pas d'accord. D'une part parce que $? n'est pas du tout équivoque, c'est le code de retour de la dernière commande exécutée, d'autre part parce que passe par des variables intermédiaires c'est utiliser plus de mémoire, consommer plus de ressources d'une manière générale. Et c'est une très mauvaise habitude de ne pas économiser ses ressources.
Tshaw Schott Front de Libération de la Ligne de Commande, canal hystérique
Bernard Déléchamp
Mais dans ce cas, pourquoi se casser la tête, autant tester directement: /etc/firewall.sh [ $? -eq 0 ] && touch ...
et encore mieux, le tout sur une seule ligne: /etc/firewall.sh && touch ...
On peut aussi préférer, pour cause de lisibilité peut-être plus évidente et intituive, l'équivalent avec if :
if /etc/firewall.sh ; then touch ... autre action... fi
et, pour inverser le test :
if ! /etc/firewall.sh ; then
-- Le directeur est rentré chez lui, l'école verrouillée.
Mais dans ce cas, pourquoi se casser la tête, autant tester directement:
/etc/firewall.sh
[ $? -eq 0 ] && touch ...
et encore mieux, le tout sur une seule ligne:
/etc/firewall.sh && touch ...
On peut aussi préférer, pour cause de lisibilité peut-être plus évidente
et intituive, l'équivalent avec if :
if /etc/firewall.sh ; then
touch ...
autre action...
fi
et, pour inverser le test :
if ! /etc/firewall.sh ; then
--
Le directeur est rentré chez lui, l'école verrouillée.
