Savoir si un nombre est décimal

Bonjour,

Je voudrais faire un test pour vérifier que le nombre dans une variable est un nombre décimal.
J'ai trouvé un test pour savoir si j'ai nombre (décimal ou pas) mais pas juste décimal

Code:

---

1 2 3 4 5

if ! [[ "$nombre" =~ ^[0-9]+([.][0-9]+)?$ ]] then echo "Ceci n'est pas un nombre" fi

---

Si au passage quelqu'un pouvait m'expliquer comment la commande fonctionne car là où je l'ai trouvé il n'y avait aucune explication (que signifie =~ pourquoi le + à la fin dans la parenthèse, le ? et le dollar).
Merci

Bonjour,

=~ compare la partie gauche à une regex (à droite).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

$ decimal='^[0-9]*\.[0-9]?[0-9]*$' $ [[ ab.ced =~ $decimal ]] && echo decimal || echo pas decimal pas decimal $ [[ 10 =~ $decimal ]] && echo decimal || echo pas decimal pas decimal $ [[ 10.23 =~ $decimal ]] && echo decimal || echo pas decimal decimal $ [[ .23 =~ $decimal ]] && echo decimal || echo pas decimal decimal $ [[ 0.23 =~ $decimal ]] && echo decimal || echo pas decimal decimal $ [[ a.23 =~ $decimal ]] && echo decimal || echo pas decimal pas decimal

---

cependant, une regex n'est pas indispensable, on peut utiliser correspondance de motif étendue (Pattern Matching, extglob) :

Code:

---

1 2 3 4 5 6

$ [[ 10.23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal decimal $ [[ ab.23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal pas decimal $ [[ .23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal decimal

---

Variante awk:

Code:

---

1 2 3

$ VAR=0.899 $ echo $VAR | awk '$0-int($0){print "est dédimal"}' est dédimal

---

Une chose que je comprends pas c'est: pourquoi n'a t'on pas besoin de bc, puisque par défaut bash ne gère pas les nombres décimaux ?

Citation:

---

Envoyé par Erlen

pourquoi n'a t'on pas besoin de bc, puisque par défaut bash ne gère pas les nombres décimaux ?

---

parce qu'on peut tester uniquement le format de la chaîne :
la chaîne se compose de
aucun, un, ou plusieurs chiffres
un point
un, ou plusieurs chiffres.

on n'effectue aucun calcul.

Ok je te remercie.

Citation:

---

Envoyé par N_BaH

cependant, une regex n'est pas indispensable, on peut utiliser correspondance de motif étendue (Pattern Matching, extglob) :

Code:

---

1 2 3 4 5 6

$ [[ 10.23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal decimal $ [[ ab.23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal pas decimal $ [[ .23 == *([0-9]).+([0-9]) ]] && echo decimal || echo pas decimal decimal

---

---

Du coup, ça marche aussi en ksh ! Merci, N_BaH !

Je ne suis pas très familier de ces expressions génériques (comme on dit dans mon Korn) où les * + ? @ et ! précèdent les parenthèses!

Toute petite remarque: le test vérifie si la chaîne est ou non un décimal en notation ango-américaine. Avec un locale français, il faudrait remplacer le point par une virgule ! (j'ai déjà eu un script de ce genre qui a échoué lorsqu'il a été déployé sur une architecture différente de celle de développement)

Un dernière question dans la même veine, peut on vérifier si un nombre possède une ou deux decimales

ici l'utilisation de regex se jusitifie :

Code:

---

1 2 3

decimal='^[0-9]*\.([0-9]?[0-9]*)$' nombre=".23" [[ $nombre =~ $decimal ]] && echo "${#BASH_REMATCH[1]} décimale(s) dans $nombre"

---

Hello à tous,

Juste histoire d'apporter mon grain de sel (et de faire le malin ;)), je signale le cas particulier du nombre entier écrit avec ses zéros non significatifs : « 50.000 ».

Deux façons de voir les choses : soit on considère que l'expression précise des décimales, fussent-elles nulles, que l'on peut évaluer et, dans ce cas, les expressions ci-dessus conviennent très bien, soit on considère qu'un nombre est décimal si sa partie rationnelle est non-nulle et là, il faut une expression qui recherche un nombre qui contienne au moins un chiffre non nul après la virgule. Par exemple : « [0-9]+\.0*[1-9]+[0-9]* ».

Citation:

---

Envoyé par Obsidian

Hello à tous,

Juste histoire d'apporter mon grain de sel (et de faire le malin ;)), je signale le cas particulier du nombre entier écrit avec ses zéros non significatifs : « 50.000 ».

Deux façons de voir les choses : soit on considère que l'expression précise des décimales, fussent-elles nulles, que l'on peut évaluer et, dans ce cas, les expressions ci-dessus conviennent très bien, soit on considère qu'un nombre est décimal si sa partie rationnelle est non-nulle et là, il faut une expression qui recherche un nombre qui contienne au moins un chiffre non nul après la virgule. Par exemple : « [0-9]+\.0*[1+9]+[0-9]* ».

---

Salut

Mathématiquement, les ensembles de nombres s'incluent tous en intégralité les uns les autres. Ainsi les nombres naturels sont inclus dans l'ensemble des nombres relatifs (avec comme caractéristique qu'ils font partie du coté positif). Les nombres relatifs positifs et négatifs sont inclus dans l'ensemble des nombres décimaux (avec comme caractéristique une partie décimale nulle). Les nombres décimaux sont inclus dans l'ensemble des rationnels (avec comme caractéristique un dénominateur pouvant toujours être exprimé comme une puissance de 10). Les rationnels sont inclus dans les irrationnels (avec comme caractéristique un numérateur et un dénominateur entier). Les irrationnels sont inclus dans les complexes (avec comme caractéristique une partie imaginaire nulle).

Donc mathématiquement, 50.000 est bien un décimal (et aussi un rationnel et aussi un irrationnel et aussi un complexe).

En revanche, personne n'a pensé au nombre "-50.000"...

Voici ma proposition: remplacer chaque chiffre, et le premier ".", et le signe "-" s'il est placé en début de nombre; par rien et regarder s'il reste quelque chose.
Ce qui donne test -z `echo $n |sed –e "s/[0-9]//g" –e "s/\.//" –e "s/^-//"` && echo "$n est nombre" || echo "$n n'est pas nombre".
Et c'est facilement adaptable à l'expression "+50.000" si on veut pousser le bouchon...

Citation:

---

Envoyé par Sve@r

Voici ma proposition: remplacer chaque chiffre, et le premier ".", et le signe "-" s'il est placé en début de nombre; par rien et regarder s'il reste quelque chose.
Ce qui donne test -z `echo $n | sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"` && echo "$n est nombre" || echo "$n n'est pas nombre".
Et c'est facilement adaptable à l'expression "+50.000" si on veut pousser le bouchon...

---

[chipotage]
Ouais... C'est pas faux!... je veux dire la spec: "remplacer chaque chiffre, et le premier ".", et le signe "-" s'il est placé en début de nombre; par rien" me paraît plutôt bien...
sauf que la mise en œuvre n'est pas aussi précise que je l'eusse souhaité...

Devinette: Que se passe-t-il pour n=3-4 ???
[/chipotage]

[chipotage]
PS: Tes -e sont difficiles à copier car ils possèdent un caractère différent du "vrai" tiret :?
[/chipotage]

Citation:

---

Envoyé par jack-ft

sauf que la mise en œuvre n'est pas aussi précise que je l'eusse souhaité...

---

Je ne comprends pas trop où est le souci...

Citation:

---

Envoyé par jack-ft

Devinette: Que se passe-t-il pour n=3-4 ???

---

Pas de souci. Etant donné que mon sed ne recherche le "-" qu'en début de chaine (le "^-") pour le remplacer par rien, celui-ci n'étant pas en début ne sera pas remplacé donc au final il restera quelque chose. Donc test -z renverra "faux" donc "3-4" ne sera pas vu comme nombre...

Citation:

---

Envoyé par jack-ft

PS: Tes -e sont difficiles à copier car ils possèdent un caractère différent du "vrai" tiret :?

---

Oui, désolé. C'est parce que j'ai tiré cet exemple de mon cours shell (parce que j'avais déjà pensé à ce problème quand j'ai écrit mon cours) lequel possède une mise en page et format spécifique. Et dans ce cours, les "tirets" sont des traits d'union insécable. Mais peut-être peux-tu essayer d'aller au delà du ctrl-c/ctrl-v...:mrgreen:

Citation:

---

Envoyé par Sve@r

Je ne comprends pas trop où est le souci...

---

Et il ne voit pas où est le souci ? :lol:

Citation:

---

Pas de souci. Etant donné que mon sed ne recherche le "-" qu'en début de chaine (le "^-") pour le remplacer par rien, celui-ci n'étant pas en début ne sera pas remplacé donc au final il restera quelque chose. Donc test -z renverra "faux" donc "3-4" ne sera pas vu comme nombre...

---

Il me semble que tu emploies beaucoup de verbes au futur... (ce qui est ton droit le plus strict, évidemment!)
Puis-je en déduire que tu n'as pas vérifié? ;)
Parce que, chez moi:

Code:

---

1 2 3

$ n=3-4 $ test -z `echo $n | sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"` && echo "$n est nombre" || echo "$n n'est pas nombre" 3-4 est nombre

---

Donc, d'après ce test, "3-4" a été vu comme un nombre (au passé composé!) ;)

En effet, le remplacement de "^-" ("-" en début de chaîne) a été fait APRÈS la suppression des nombres en début de chaîne, ce qui fait que ce code remplace aussi le premier "-" placé après tous les premiers chiffres!

D'ailleurs, il en serait de même pour "n=34-".

Pour corriger cette coquille, il me semble qu'il suffit juste de permuter l'ordre des instructions sed:

Code:

---

1 2 3

$ n=3-4 $ test -z `echo $n | sed -e "s/^-//" -e "s/[0-9]//g" -e "s/\.//"` && echo "$n est nombre" || echo "$n n'est pas nombre" 3-4 n'est pas nombre

---

On peut même ajouter le '+':

Code:

---

$ test -z `echo $n | sed -e 's/^[+-]//' -e 's/[0-9]//g' -e 's/\.//'` && echo "$n est nombre" || echo "$n n'est pas nombre"

---

Évidemment, il restera toujours quelques petits bugs: n="" ou n="-" ou n="-." qui risquent fort de faire des faux positifs!

Citation:

---

Oui, désolé. C'est parce que j'ai tiré cet exemple de mon cours shell (parce que j'avais déjà pensé à ce problème quand j'ai écrit mon cours)

---

cours à corriger asap, donc... ;)

Citation:

---

lequel possède une mise en page et format spécifique. Et dans ce cours, les "tirets" sont des traits d'union insécable.

---

Ok! Je comprends!

Citation:

---

Mais peut-être peux-tu essayer d'aller au delà du ctrl-c/ctrl-v...:mrgreen:

---

Ben, c'est ce que j'ai fait (cf. la citation)! :mrgreen:

[super-chipotage]
Sous mon AIX 6.1, la fonction "test" est assez susceptible:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ n= $ test -z $n ksh: test: argument expected   $ n=3 $ test -z `echo $n |sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"` && echo "# $n est nombre" || echo "# $n n'est pas nombre" ksh: test: argument expected # 3 n'est pas nombre   $ [[ -z $(echo $n |sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//") ]] && echo "# $n est nombre" || echo "# $n n'est pas nombre" # 3 est nombre

---

De la simplicité de la portabilité (again!)... :grrr: :ouin:

[/super-chipotage]

la commande test demande que si on ne sait pas de combien de mots est composée une variable, cette dernière soit mise entre guillemets (en gros, tout le temps :)).
les [[ sont plus souples à ce propos.

Citation:

---

Envoyé par N_BaH

la commande test demande que si on ne sait pas de combien de mots est composée une variable, cette dernière soit mise entre guillemets (en gros, tout le temps :)).
les [[ sont plus souples à ce propos.

---

Oui, je sais, mais, avec les backquotes et les guillemets, c'est pas commode!

On ne peut pas juste ajouter un guillemet (entre quotes!):

Code:

---

1 2 3 4 5 6

$ n=35 $ test -z "'"`echo $n | sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"`"'" && echo "# $n est nombre" || echo "# $n n'est pas nombre" # 35 n'est pas nombre   $ test -z "`echo $n |sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"`" && echo "# $n est nombre" || echo "# $n n'est pas nombre" # 35 est nombre

---

J'avoue que ma confiance est plutôt limitée en ce qui concerne les imbrications de guillemets, backquotes et de nouveau guillemets... (ça me fait flipper!)

Le shell est quand même un drôle de langage (pour la gestion des arguments et des espaces!).

Code:

---

1 2 3 4 5 6

set -x; test -z "'"`echo $n | sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"`"'" && echo "# $n est nombre" || echo "# $n n'est pas nombre"; set +x ++ sed -e 's/[0-9]//g' -e 's/\.//' -e 's/^-//' ++ echo 35 + test -z ''\'''\''' + echo '# 35 n'\''est pas nombre' # 35 n'est pas nombre

---

pourquoi ajouter des apostrophes ? car au final elles persistent.

Bonjour,

Je suis surpris du débat que j'ai malgré moi lancé et dont j'avoue je ne suis pas sur de tout comprendre.
Je reviens sur ma dernière question:

Citation:

---

Envoyé par N_BaH

ici l'utilisation de regex se jusitifie :

Code:

---

1 2 3

decimal='^[0-9]*\.([0-9]?[0-9]*)$' nombre=".23" [[ $nombre =~ $decimal ]] && echo "${#BASH_REMATCH[1]} décimale(s) dans $nombre"

---

---

Ce n'est pas exactement ce que je cherche, car cette expression me dit si le nombre possède un ou deux décimales et ce que je voulais faire c'était :

Code:

---

1 2 3 4 5 6 7 8

if [[ "$nombre" = une décimale ]] then echo ce nombre a une décimale elif [[ "$nombre" = deux décimale ]] then echo ce nombre a deux décimales fi

---

Dans mon script il y a deux possibilités soit on fait tout avec une décimale soit tout avec deux et comme les $nombre sont rentrés par l'utilisateur je veux vérifier qu'il ne c'est pas trompé que tous reste cohérents (quand on écrit un script pour soit c'est rapide on s'en fou, on sait comment il marche mais si d'autres doivent s'en servir c'est le bazar, je comprends maintenant quand les gens disent que la gestion des bugs est important, faut tout vérifier)

La méthode proposer m'oblige à faire un test, sur le résultat ${#BASH_REMATCH[1]} du test précédent

àmha, ce que tu souhaites n'est pas réalisable tel quel :(
je persiste :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

decimal="^[+-]?[0-9]*[.,]([0-9]+)$" for n in 0.000 .000 0.1 .1 0.23 .23 50 -50 50.000 -50.000 abc abc.def 00.def abc.000 do [[ $n =~ $decimal ]] case ${#BASH_REMATCH[1]} in 1) echo "$n a 1 décimale";; 2) echo "$n a 2 décimales";; *) echo "$n a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre" esac done 0.000 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre .000 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre 0.1 a 1 décimale .1 a 1 décimale 0.23 a 2 décimales .23 a 2 décimales 50 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre -50 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre 50.000 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre -50.000 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre abc a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre abc.def a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre 00.def a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre abc.000 a plus de 2 décimales, ou est un nombre entier, ou encore n'est pas un nombre

---

NBaH.

Citation:

---

Envoyé par jack-ft

Et il ne voit pas où est le souci ? :lol:
...


Il me semble que tu emploies beaucoup de verbes au futur... (ce qui est ton droit le plus strict, évidemment!)
Puis-je en déduire que tu n'as pas vérifié? ;)
Parce que, chez moi:

Code:

---

1 2 3

$ n=3-4 $ test -z `echo $n | sed -e "s/[0-9]//g" -e "s/\.//" -e "s/^-//"` && echo "$n est nombre" || echo "$n n'est pas nombre" 3-4 est nombre

---

Donc, d'après ce test, "3-4" a été vu comme un nombre (au passé composé!) ;)

En effet, le remplacement de "^-" ("-" en début de chaîne) a été fait APRÈS la suppression des nombres en début de chaîne, ce qui fait que ce code remplace aussi le premier "-" placé après tous les premiers chiffres!

D'ailleurs, il en serait de même pour "n=34-".

Pour corriger cette coquille, il me semble qu'il suffit juste de permuter l'ordre des instructions sed:

Code:

---

1 2 3

$ n=3-4 $ test -z `echo $n | sed -e "s/^-//" -e "s/[0-9]//g" -e "s/\.//"` && echo "$n est nombre" || echo "$n n'est pas nombre" 3-4 n'est pas nombre

---

On peut même ajouter le '+':

Code:

---

$ test -z `echo $n | sed -e 's/^[+-]//' -e 's/[0-9]//g' -e 's/\.//'` && echo "$n est nombre" || echo "$n n'est pas nombre"

---

Évidemment, il restera toujours quelques petits bugs: n="" ou n="-" ou n="-." qui risquent fort de faire des faux positifs!

cours à corriger asap, donc... ;)

---

Totalement exact. J'ai totalement foiré mon exo...8O
Donc j'abandonne la méthode "remplacement" et je passe à la méthode "grep". Un bon filtre egrep sur une regex bien ficelée et soit le nombre ressort, soit rien. Mais bon, cette soluce ayant déjà été proposée par N_Bah en fait j'ai plus rien à montrer. :calim2: