Differences between revisions 14 and 45 (spanning 31 versions)
Revision 14 as of 2008-06-13 18:51:30
Size: 6054
Editor: 74-140-161-210
Comment: mention read's arithmetic evaluation
Revision 45 as of 2015-03-01 16:03:15
Size: 4661
Editor: pdm-l03
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
[[Anchor(faq54)]] <<Anchor(faq54)>>
Line 3: Line 4:
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 6:
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. This can be checked using standard [:glob:globs]: === Hand parsing ===
If you're validating a simple "string of digits", you can do it with a [[glob]]:
Line 8: Line 11:
if [[ $foo = *[^0-9]* ]]; then if [[ $foo != *[!0-9]* ]]; then
    echo "'$foo' is strictly numeric"
else
Line 10: Line 15:
else
    echo "'$foo' is strictly numeric"
Line 14: Line 17:
Line 18: Line 20:
# ksh, POSIX
case "$foo" in
    *[!0-9]*) echo "'$foo' has a non-digit somewhere in it" ;;
    *) echo "'$foo' is strictly numeric" ;;
# POSIX
case $var in
    '')
        printf 'var is empty\n';;
    *[!0-9]*)
        printf '%s has a non-digit somewhere in it\n' "$var";;
    *)
        printf '%s is strictly numeric\n' "$var";;
esac >&2
}}}
Of course, if all you care about is vald vs. invalid, you can combine cases:

{{{
# POSIX
case $var in
    '' | *[!0-9]*)
        echo "$0: $var: invalid digit" >&2; exit 1;;
Line 24: Line 39:

If what you actually mean is "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]:
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 you can trim off any sign and then compare:
Line 28: Line 42:
# Bash -- extended globs must be enabled. # POSIX
case ${var#[-+]} in # notice ${var#prefix} substitution to trim sign
    '')
        printf 'var is empty\n';;
    *.*.*)
        printf '%s has more than one decimal point in it\n' "$var";;
    *[!0-9.]*)
        printf '%s has a non-digit somewhere in it\n' "$var";;
    *)
        printf '%s looks like a valid float\n' "$var";;
esac >&2
}}}
Or in Bash, we can use [[glob|extended globs]]:

{{{
# Bash -- extended globs must be enabled explicitly in versions prior to 4.1.
Line 31: Line 60:
[[ $var == +([0-9]) ]] [[ $var = +([0-9]) ]]
Line 33: Line 62:
Line 37: Line 65:
# Bash # Bash / ksh
Line 39: Line 67:
[[ $foo = *[0-9]* && $foo = ?([+-])*([0-9])?(.*([0-9])) ]] &&
  echo "foo is a floating-point number"

if
[[ $foo = @(*[0-9]*|!([+-]|)) && $foo = ?([+-])*([0-9])?(.*([0-9])) ]]; then
  echo 'foo is a floating-point number'
fi
Line 42: Line 72:
Optionally, `case..esac` may have been used in shells with extended pattern matching. The leading test of {{{$foo}}} is to ensure that it contains at least one digit, isn't empty, and contains more than just + or - by itself.
Line 43: Line 74:
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.

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:

{{{
# ksh - extended globs are on by default
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 [:RegularExpression:regular expression] syntax. 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 63: Line 78:
if test "$foo" && echo "$foo" | egrep '^[-+]?[0-9]*(\.[0-9]*)?$' >/dev/null
then
    echo "'$foo' might be a number"
if echo "$foo" | grep -qE '^[-+]?([0-9]+\.?|[0-9]*\.[0-9]+)$'; then
    echo "'$foo' is a number"
Line 67: Line 81:
    echo "'$foo' might not be a number"     echo "'$foo' is not a number"
Line 70: Line 84:

(Like the extended globs, this [:RegularExpression:extended regular expression] will match a lone {{{+}}} or {{{-}}}. 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.
Line 76: Line 87:
# Bash 3.1 ONLY
if [[ $foo = *[0-9]* && $foo =~ ^[-+]?[0-9]*\(\.[0-9]*\)?$ ]]; then
# Bash
# The regexp must be stored in a var and expanded for backward compatibility with versions < 3.2

regexp='^[-+]?[0-9]*(\.[0-9]*)?$'
if [[ $foo = *[0-9]* && $foo =~ $regexp ]]; then
Line 83: Line 97:
=== 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 an integer because of the `-eq`. If the parsing succeeds 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 84: Line 106:
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: Be careful: the following trick with `printf` (no supported by all shells)
Line 87: Line 109:
# Bash 3.2 *PATCHED* only!
if [[ $foo = *[0-9]* && $foo =~ ^[-+]?[0-9]*(\.[0-9]*)?$ ]]; then
    echo "'$foo' looks rather like a number"
else
    echo "'$foo' doesn't look particularly numeric to me"
# BASH
if printf %f "$foo" >/dev/null 2>&1; then
  echo "$foo is a float"
Line 94: Line 114:
is broken: about the arguments of the{{{ a}}}, {{{A}}}, {{{e}}}, {{{E}}}, {{{f}}}, {{{F}}}, {{{g}}}, or {{{G}}} format modifiers, POSIX specifies that ''if the leading character is a single-quote or double-quote, the value shall be the numeric value in the underlying codeset of the character following the single-quote or double-quote.'' Hence this fails when {{{foo}}} expands to a string with a leading single-quote or double-quote: the previous command will happily validate the string as a float.
Line 95: Line 116:
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....

If you just want to guarantee ahead of time that a variable contains an integer, without actually checking, you can give the variable the "integer" attribute.

{{{
declare -i foo
foo=-10+1; echo "$foo" # prints -9

foo="hello"; echo "$foo"
# the value of the variable "hello" is evaluated; if unset, foo is 0

foo="Some random string" # results in an error.
}}}

Any value assigned to a variable with the integer attribute set is evaluated as an [:ArithmeticExpression:arithmetic expression] just like inside `$(( ))`. Bash will raise an error if you try to assign an invalid arithmetic expression.

In Bash and ksh93, if a variable which has been declared integer is used in a `read` command, the user's input is treated as an [:ArithmeticExpression;arithmetic expression], as with assignment. In particular, if the user types an identifier, the variable will be set to the value of the variable with that name, and `read` will give no other indication of a problem.

{{{
# Bash (and ksh93, if you replace declare with typeset)
$ declare -i foo
$ read foo
hello
$ echo $foo # prints 0; 'hello' is unset, so is treated as 0 for arithmetic purposes
$ hello=5
$ read foo # user types hello again
hello
$ echo $foo # prints 5, the value of 'hello' as an arithmetic expression
}}}

Pretty useless if you want to read only integers.

In the older Korn shell (ksh88), if a variable is declared integer and used in a `read` command, and the user types an invalid integer, the shell complains, the read command returns an error status, and the value of the variable is unchanged.

{{{
# ksh88
$ typeset -i foo
$ foo=42
$ read foo
hello
ksh: hello: bad number
$ echo $?
1
$ echo $foo
42
}}}
You can use `%d` to parse an integer. Take care that the parsing might be (is supposed to be?) [[locale]]-dependent.

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:

# POSIX
case $var in
    '')
        printf 'var is empty\n';;
    *[!0-9]*)
        printf '%s has a non-digit somewhere in it\n' "$var";;
    *)
        printf '%s is strictly numeric\n' "$var";;
esac >&2

Of course, if all you care about is vald vs. invalid, you can combine cases:

# POSIX
case $var in
    '' | *[!0-9]*)
        echo "$0: $var: invalid digit" >&2; exit 1;;
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 you can trim off any sign and then compare:

# POSIX
case ${var#[-+]} in   # notice ${var#prefix} substitution to trim sign
    '')
        printf 'var is empty\n';;
    *.*.*)
        printf '%s has more than one decimal point in it\n' "$var";;
    *[!0-9.]*)
        printf '%s has a non-digit somewhere in it\n' "$var";;
    *)
        printf '%s looks like a valid float\n' "$var";;
esac >&2

Or in Bash, we can use extended globs:

# Bash -- extended globs must be enabled explicitly in versions prior to 4.1.
# Check whether the variable is all digits.
shopt -s extglob
[[ $var = +([0-9]) ]]

A more complex case:

# Bash / ksh
shopt -s extglob

if [[ $foo = @(*[0-9]*|!([+-]|)) && $foo = ?([+-])*([0-9])?(.*([0-9])) ]]; then
  echo 'foo is a floating-point number'
fi

Optionally, case..esac may have been used in shells with extended pattern matching. The leading test of $foo is to ensure that it contains at least one digit, isn't empty, and contains more than just + or - by itself.

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" | grep -qE '^[-+]?([0-9]+\.?|[0-9]*\.[0-9]+)$'; 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.

# Bash
# The regexp must be stored in a var and expanded 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 an integer because of the -eq. If the parsing succeeds 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.

Be careful: the following trick with printf (no supported by all shells)

# BASH
if printf %f "$foo" >/dev/null 2>&1; then
  echo "$foo is a float"
fi

is broken: about the arguments of the a, A, e, E, f, F, g, or G format modifiers, POSIX specifies that if the leading character is a single-quote or double-quote, the value shall be the numeric value in the underlying codeset of the character following the single-quote or double-quote. Hence this fails when foo expands to a string with a leading single-quote or double-quote: the previous command will happily validate the string as a float.

You can use %d to parse an integer. Take care that the parsing might be (is supposed to be?) locale-dependent.

BashFAQ/054 (last edited 2022-08-01 10:02:57 by 89)