4055
Comment: move that extglob solution up above the regex ones; add a ksh-based one too; clean up a lot
|
4276
toc broken again
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
[[Anchor(faq54)]] | <<Anchor(faq54)>> |
Line 3: | Line 3: |
First, you have to define what you mean by "number". The most common case when people ask this seems to be "a non-negative integer, with no leading + sign". Or in other words, a string of all digits. Other times, people want to validate a floating-point input, with optional sign and optional decimal point. | |
Line 4: | Line 5: |
First, you have to define what you mean by "number". The most common case seems to be that, when people ask this, they actually mean "a non-negative integer, with no leading + sign". Or in other words, a string of all digits. | === Hand parsing === If you're validating a simple "string of digits", you can do it with a [[glob]]: |
Line 7: | Line 9: |
if [[ $foo = *[^0-9]* ]]; then | # Bash if [[ $foo != *[!0-9]* ]]; then echo "'$foo' is strictly numeric" else |
Line 9: | Line 14: |
else echo "'$foo' is strictly numeric" |
|
Line 13: | Line 16: |
This can be done in Korn and legacy Bourne shells as well, using {{{case}}}: |
The same thing can be done in Korn and POSIX shells as well, using {{{case}}}: |
Line 17: | Line 19: |
# ksh, POSIX | |
Line 22: | Line 25: |
If what you actually mean is "a valid floating-point number" or something else more complex, then there are a few possible ways. One of them is to use Bash's {{{extglob}}} capability: |
If you need to allow a leading negative sign, or if want a valid floating-point number or something else more complex, then there are a few possible ways. Standard globs aren't expressive enough to do this, but we can use [[glob|extended globs]]: |
Line 26: | Line 28: |
# Bash example; extended globs are disabled by default | # Bash -- extended globs must be enabled. # Check whether the variable is all digits. |
Line 28: | Line 31: |
[[ $foo = *[0-9]* && $foo = ?([+-])*([0-9])?(.*([0-9])) ]] && echo "foo is a number" | [[ $var == +([0-9]) ]] |
Line 30: | Line 33: |
A more complex case: | |
Line 31: | Line 35: |
{{{ # Bash shopt -s extglob [[ $foo = *[0-9]* && $foo = ?([+-])*([0-9])?(.*([0-9])) ]] && echo "foo is a floating-point number" }}} |
|
Line 33: | Line 43: |
The features enabled with {{{extglob}}} in Bash are also allowed in the Korn shell by default. The difference here is that Ksh lacks Bash's {{{[[}}} and must use {{{case}}} instead: | Korn shell has extended globs enabled by default, but lacks `[[`, so we must use `case` to do the glob-matching: |
Line 36: | Line 46: |
# Ksh example using extended globs | # Korn |
Line 44: | Line 54: |
Note that this uses the same extended glob as the Bash example before it; the third closing parenthesis at the end of it is actually part of the case syntax. | |
Line 45: | Line 56: |
Note that this uses the same extended glob as the Bash example before it; the third closing parenthesis at the end of it is actually part of the {{{case}}} syntax. If your definition of "a valid number" is even more complex, or if you need a solution that works in legacy Bourne shells, you might prefer to use a regular expression. Here is a portable version, using {{{egrep}}}: |
If your definition of "a valid number" is even more complex, or if you need a solution that works in legacy Bourne shells, you might prefer to use an external tool's [[RegularExpression|regular expression]] syntax. Here is a portable version (explained in detail [[http://www.wplug.org/wiki/Meeting-20100612#EXERCISE_TWO|here]]), using {{{egrep}}}: |
Line 50: | Line 59: |
if test "$foo" && echo "$foo" | egrep '^[-+]?[0-9]*(\.[0-9]*)?$' >/dev/null; then echo "'$foo' might be a number" |
# Bourne if echo "$foo" | egrep '^[-+]?([0-9]+\.?|[0-9]*\.[0-9]+)$' >/dev/null then echo "'$foo' is a number" |
Line 53: | Line 64: |
echo "'$foo' might not be a number" | echo "'$foo' is not a number" |
Line 56: | Line 67: |
(Like the extended globs, this extended regular expression matches a lone {{{+}}} or {{{-}}}, and the code may therefore require adjustment. The initial {{{test}}} command only requires a non-empty string. Closing the last "bug" is left as an exercise for the reader, mostly because GreyCat is too damned lazy to learn {{{expr(1)}}}.) Bash version 3 and above have regular expression support in the [[ command. However, due to serious bugs and syntax changes in Bash's [[ regex support, we '''do not recommend''' using it. Nevertheless, if I simply omit all Bash regex answers here, someone will come along and fill them in -- and they probably won't work, or won't contain all the caveats necessary. So, in the interest of preventing disasters, here are the Bash regex answers that you should not use. |
Bash version 3 and above have regular expression support in the [[ command. Due to bugs and changes in the implementation of the `=~` feature throughout bash 3.x, we '''do not recommend''' using it, but people do it anyway, so we have to maintain this example (''and keep restoring this warning, too, when people delete it''): |
Line 62: | Line 70: |
if [[ $foo = *[0-9]* && $foo =~ ^[-+]?[0-9]*\(\.[0-9]*\)?$ ]]; then # Bash 3.1 only! | # Bash # Put the RE in a var for backward compatibility with versions <3.2 regexp='^[-+]?[0-9]*(\.[0-9]*)?$' if [[ $foo = *[0-9]* && $foo =~ $regexp ]]; then |
Line 68: | Line 79: |
=== Using the parsing done by [ and printf (or "using eq") === {{{ # fails with ksh if [ "$foo" -eq "$foo" ] 2>/dev/null;then echo "$foo is an integer" fi }}} `[` parses the variable and interprets it as in integer because of the `-eq`. If the parsing succeds the test is trivially true; if it fails `[` prints an error message that `2>/dev/null` hides and sets a status different from 0. However this method fails if the shell is ksh, because ksh evaluates the variable as an arithmetic expression. |
|
Line 69: | Line 88: |
Unfortunately, Bash changed the syntax of its regular expression support after version 3.1, so the following ''may'' work in some patched versions of Bash 3.2: | You can use a similar trick with `printf`: |
Line 72: | Line 91: |
if [[ $foo = *[0-9]* && $foo =~ ^[-+]?[0-9]*(\.[0-9]*)?$ ]]; then # **PATCHED** Bash 3.2 only! echo "'$foo' looks rather like a number" else echo "'$foo' doesn't look particularly numeric to me" |
# POSIX if printf "%f" "$foo" >/dev/null 2>&1; then echo "$foo is a float" |
Line 78: | Line 96: |
You can use `%d` to parse an integer. Take care that the parsing might be (is supposed to be?) [[locale]]-dependent. | |
Line 79: | Line 98: |
It fails rather spectacularly in bash 3.1 and in bash 3.2 without patches. Note that the parentheses in the {{{egrep}}} regular expression and the bash 3.2.patched regular expression don't require backslashes in front of them, whereas the ones in the bash 3.1 command do. Stuffing the Bash regex into a variable, and then using {{{[[ $foo =~ $bar ]]}}}, may also be an effective workaround in some cases. But this belongs in a separate FAQ.... |
=== Using ((...)) to determine if input is integer === {{{ if (("$foo")) >/dev/null 2>&1; then echo "$foo is an integer" fi }}} the command (($foo)) tries to parse foo as an integer arithmetic expression, which returns a non-zero error code if foo is not an integer. |
How can I tell whether a variable contains a valid number?
First, you have to define what you mean by "number". The most common case when people ask this seems to be "a non-negative integer, with no leading + sign". Or in other words, a string of all digits. Other times, people want to validate a floating-point input, with optional sign and optional decimal point.
Hand parsing
If you're validating a simple "string of digits", you can do it with a glob:
# Bash if [[ $foo != *[!0-9]* ]]; then echo "'$foo' is strictly numeric" else echo "'$foo' has a non-digit somewhere in it" fi
The same thing can be done in Korn and POSIX shells as well, using case:
# ksh, POSIX case "$foo" in *[!0-9]*) echo "'$foo' has a non-digit somewhere in it" ;; *) echo "'$foo' is strictly numeric" ;; esac
If you need to allow a leading negative sign, or if want a valid floating-point number or something else more complex, then there are a few possible ways. Standard globs aren't expressive enough to do this, but we can use extended globs:
# Bash -- extended globs must be enabled. # Check whether the variable is all digits. shopt -s extglob [[ $var == +([0-9]) ]]
A more complex case:
# Bash shopt -s extglob [[ $foo = *[0-9]* && $foo = ?([+-])*([0-9])?(.*([0-9])) ]] && echo "foo is a floating-point number"
The leading test of $foo is to ensure that it contains at least one digit. The extended glob, by itself, would match the empty string, or a lone + or -, which may not be desirable behavior.
Korn shell has extended globs enabled by default, but lacks [[, so we must use case to do the glob-matching:
# Korn case $foo in *[0-9]*) case $foo in ?([+-])*([0-9])?(.*([0-9]))) echo "foo is a number";; esac;; esac
Note that this uses the same extended glob as the Bash example before it; the third closing parenthesis at the end of it is actually part of the case syntax.
If your definition of "a valid number" is even more complex, or if you need a solution that works in legacy Bourne shells, you might prefer to use an external tool's regular expression syntax. Here is a portable version (explained in detail here), using egrep:
# Bourne if echo "$foo" | egrep '^[-+]?([0-9]+\.?|[0-9]*\.[0-9]+)$' >/dev/null then echo "'$foo' is a number" else echo "'$foo' is not a number" fi
Bash version 3 and above have regular expression support in the [[ command. Due to bugs and changes in the implementation of the =~ feature throughout bash 3.x, we do not recommend using it, but people do it anyway, so we have to maintain this example (and keep restoring this warning, too, when people delete it):
# Bash # Put the RE in a var for backward compatibility with versions <3.2 regexp='^[-+]?[0-9]*(\.[0-9]*)?$' if [[ $foo = *[0-9]* && $foo =~ $regexp ]]; then echo "'$foo' looks rather like a number" else echo "'$foo' doesn't look particularly numeric to me" fi
Using the parsing done by [ and printf (or "using eq")
# fails with ksh if [ "$foo" -eq "$foo" ] 2>/dev/null;then echo "$foo is an integer" fi
[ parses the variable and interprets it as in integer because of the -eq. If the parsing succeds the test is trivially true; if it fails [ prints an error message that 2>/dev/null hides and sets a status different from 0. However this method fails if the shell is ksh, because ksh evaluates the variable as an arithmetic expression.
You can use a similar trick with printf:
# POSIX if printf "%f" "$foo" >/dev/null 2>&1; then echo "$foo is a float" fi
You can use %d to parse an integer. Take care that the parsing might be (is supposed to be?) locale-dependent.
Using ((...)) to determine if input is integer
if (("$foo")) >/dev/null 2>&1; then echo "$foo is an integer" fi
the command (($foo)) tries to parse foo as an integer arithmetic expression, which returns a non-zero error code if foo is not an integer.