Bonjour,
 
Voilà je dois tester si un paramètre passé à mon script est de type entier. J'avais pensé utiliser typeset (plutôt qu'un bête case "$1" in...), mais j'ai un problème :

Pourquoi la redirection ne marche pas ??? C'est gênant ce message qui s'affiche.
 
Ensuite, autre problème, sûrement lié :

Ici, pourquoi le message "Erreur" ne s'affiche pas, et dans aucun cas ? J'ai vérifié le code de retour de NB="1a", c'est 1 (donc bien une erreur), donc s'il est normal que && na marche pas, les deux autres devraient...
 
Edit: Du coup pour le moment j'utilise la ligne :
 
[[ "$ARG" != *[!0-9]* && "$ARG" != "" ]] || traiterErreur
 
Ça marche bien, mais je voudrais comprendre les erreurs du dessus...

Je n'en suis pas sur, mais il me semble que typeset renvois un message sur la sortie d'erreur et non sur la sortie normal, ce qui explique pourquoi elle passe à travers le ">".
Comme une erreur est levée, l'instruction s'arrête...
 
Mais ça reste une hypothèse hein

A priori j'ai indiqué dans mon message précédent que j'avais essayé la redirection de stdout ET stderr ("commande > /dev/null" et "commande 2> /dev/null" )
Donc le problème n'est pas là non ? A moins que j'oublie quelque chose...

Et si tu utilisais grep plutôt pour savoir si c'est un entier ?
 
Edit : je viens de voir ton edit
Heu sinon l'affectation c'est pas une commande (un process indépendant). C'est de l'interprétation bash apparemment, donc la redirection de flux ça doit pas trop marcher dessus. C'est le shell bash lui même qu'il faut configurer avec des options.

Tout à fais. Celà dit tu peux rediriger le stderr de ton shell avant de lancer la commande, avec un "exec 2>/dev/null". Attention quand même, si tu veux ensuite pouvoir afficher à nouveau stderr, il faut prévoir le coup. Tu peux faire un truc du genre :

Ok... voilà donc l'astuce ! Merci.
 
Pour le coup du

j'essaierai pour voir ça m'a l'air pas mal effectivement. Merci pour l'info.
 
En revanche je n'explique pas vraiment

qui n'affiche pas le message "Error", mais je suppose que ça vient encore du même problème (le shell arrete l'éxécution de la ligne à l'erreur d'affectation)

typeset c'est un peu deprecated, ya declare maintenant :  
 
$ help typeset
typeset: typeset [-afFirtx] [-p] name[=value] ...
     Obsolete.  See `declare'.

Bash accepte les entiers sous forme "base#nombre", où base est la base de numération. Cette base est par défaut 10 (quand elle est omise).
 
"n=3;" éuivaut à "n=10#3;"
 
Par exemple, "typeset -i n; n=13#4a45; echo $n" donne 10535.
Ca veut dire que le nombre 4a45 sur la base 13 (c'est à dire écrit avec les "chiffres" 0 1 2 3 4 5 6 7 8 9 a b c) vaut 10535 en décimal.
 
Quand tu tapes NR="1a", tu ne précise pas de base, donc c'est 10 par défaut. Or "a" ne fait pas partie des chiffres de la base 10 (qui sont les chiffres de 0 à 9, dix chiffres). C'est pour cela que bash rale. D'ailleurs il se plaint précisément à propos de la "base".
 
Quant au fait de ne pas passer au "echo", je ne vois pas ce qui t'étonnes ! Quand un script rencontre une erreur, il s'arrête, c'est son comportement naturel.  
C'est peut-être que le fait que tu passe les instruction en ligne de commnde qui te perturbes.
Mais si tu mets "echo $(( 1/0 )); ls" dans fichier "err.sh" et que tu tapes "sh (ou bash ou ksh..) err.sh", tu verras jamais le résultat du "ls" ! Seulement l'erreuer résultant du 1/0 (division par 0).
 

Ca j'avais saisi... le problème c'est pourquoi le echo ne passe pas avec un enchaînement de commande en ";" ou en "||".
 

Je crée 2 scripts tests :
 
test_1.sh

test_2.sh

L'éxécution du premier s'arrête effectivement à l'erreur (idem avec un "||" à la place du ";" ). C'est ce que je ne comprends pas bien.
En revanche le 2nd affiche le 'ls'. Donc "Quand un script rencontre une erreur, il s'arrête, c'est son comportement naturel" n'est pas vrai (du moins comme je le comprends), mais le fonctionnement de ";" et "||" est différent d'un simple enchaînement de commandes.
 
De plus, si j'éxécute la commande

J'ai bien le résultat du ls qui s'affiche, pourtant la première commande lève une erreur (je n'ai pas d'interface qui s'appelle interface_bidon...). Il y a donc une différence entre certaines erreurs.
 
Je pense surtout que le shell arrête l'éxécution d'une ligne lorsqu'il rencontre une erreur du type "echo $(( 1/0 ))" ou "NB="1a"" (cas du NB entier base 10). Mais comment reconnaître une erreur de ce type d'une autre ? (Ce sont d'ailleurs toutes ces erreurs dont on ne peut rediriger la sortie).

Je n'ai pas été très clair sur la deuxième partie apparamment.
 
Sortir ou pas sur erreur, c'est une décision du développeur du programme !
 
Quant tu tapes "ifconfig bidon; ls", t'es dans bash. Il crée (fork) un processus fils où le binaire /bin/ifconfig tourne.
Quand ifconfig rencontre l'erreur due à "bidon", il s'arrête et sort. Il rend la main à son père (bash), qui passe à l'instruction suivante (ls).
Cette sortie est une décision des dévloppeurs de ifconfig, qui ont décidé que s'i l'interfacce désignée n'existait pas, alors "exit -1" ou "return -1"..
 
Reprenons le même raisonnement avec "echo $((1/0)); ls"
 
Avant d'exécuter le "echo $(( 1/0 ))", bash doit évaluer l'expression "$(( 1/0))" qu'il va passer à /usr/bin/echo lorsqu'il le "forkera". Or, les expressions arithmétiques du type "$(())" sont un "built-in" du bash: il ne va pas créer de fils pour évaluer le "$((1/0))", il le fait lui même. Et il rencontre une erreur (division par 0). Alors il affiche un message d'erreur et ne poursuit pas l'évaluation du reste de la ligne. In ne sort pas  (sinon ton promt disparaîtrait) !
Ce comportement est cette fois une décision des développeurs de bash: bash lit les instructions ligne pas ligne et les exécutes de gauche à droite.
Il se moque des erreurs arrivées au sein de ses fils, mais si c'est lui qui se heurte à une erreur, l'exécution de la ligne en cours s'arrête. C'est comme ça que bash fonctionne ! Et c'est pour ça que le fait d'éclater "echo $((1/0)); ls" en une instruction par ligne le fait passer à la ligne suivante. Il arrête l'exécution de la ligne "echo $((1/0))" dès qu'il rencontre une erreur, mais ne sort pas ! Il passe à la ligne suivante "ls".
Heureusement d'ailleurs, parce que s'il sortait suite à ses erreurs, ton terminal disparaîtrait suite au "NB=1a" par exemple !!
 
Dans "ifconfig bidon; ls", il y a erreur, mais ce n'est pas la sienne ! C'est les développeurs de ifconfig qui ont décidé de sortir (de ifconfig !). Ils auraient pu en décider autrement, mais ça aurait été légèrement gênant !
La décision de sortir uniquement sur un "exit" dans bash (et de ne pas sortir sur erreur) est due à la nature d'interpreteur d'nstruction de celui-ci.
C'est juste une (judicieuse !) décision des développeurs.
 
Donc, pour faire simple, quand c'est au shell lui même de faire le boulot (évaluer une expression comme $((1/0)), effectuer une assignation comme NB="1a", ..), si erreur il y a, c'est son problème. Alors il s'arrête (d'interpréter la ligne en cours, et ne sort pas !).
En revanche, si lerreur survient dans l'un de ses "fils" (comme /bin/ifconfig), c'est le problème du fils. C'est le fils qui s'arrête (ou pas d'ailleurs, si le fils est sh par exemple !), et rend la main au bash (ou pas !), qui poursuit jusqu'à la fin de la ligne en cours (tant qu'il-bash- ne recontre pas d'erreur), ou passe à la ligne suivante s'il a atteint la fin de ligne.
 
J'espère avoir été clair cette fois !
 
PS: Les "fils" sont facilement repérables si tu set l'option x (set -x, set +x pour la désactiver) pour déboguer: les lancements de fils  sont précédés d'un signe +.

Bon ben avec une réponse pareil, je peux me coucher maintenant... Nan sérieusement merci d'avoir pris le temps c'était super clair et du coup le sujet est résolu ! J'avais juste pas saisi que le bash évaluait lui-même les expressions (je pensais qu'il faisait un fils dans tous les cas).
Voilà merci encore !

Mini précision, pour info ...
 

 
ce comportement peut être changé par la syntaxe

en début de script
 
Ainsi, à la moindre erreur (qu'il s'agisse de bash [echo $((1/0))] ou d'une autre commande [ifconfig bidon]), l'exécution du script entier s'arrête