Home / ubuntu / Questions / 1340357
Accepted
genderbee
Asked: 2021-05-25 06:04:36 +0800 CST

bash, if decimal is greater is working strange

  • 772

I have this script to compare cpuload is greater then limit 10.

#!/bin/bash

cpuload=$(uptime | cut -d' ' -f 13 | sed '$ s/.$//')
limit=10

echo
echo "cpuload = $cpuload, limit = $limit"
echo

[[ $cpuload > $limit ]] && echo | mail -s "cpuload $cpuload is higher than $limit!" EMAIL

Now, I am receiving emails even if value is lower than limit (3 > 10).

Where is the problem?

I tried combinations with condition syntax, but sometimes it is working, sometimes not... I am little confused.

Thanks.

UPDATE

cpu_load=$(uptime | cut -d' ' -f 13 | sed '$ s/.$//')
limit=1

send_email(){
echo | mail -s "makroczsk, cpuload $cpu_load is higher than limit $limit!" $email_to
}

echo "cpuload = $cpu_load (${cpu_load%%.*}), limit = $limit"

[[ (( ${cpu_load%%.*} > $limit )) ]] && send_email
[[ ${cpu_load%%.*} -gt $limit ]] && send_email

cpuload = 3.10, limit = 10
./check-cpuload.sh: line 9: [[: 3.10: syntax error: invalid arithmetic operator (error token is ".10")

And in 1st case, emails are still coming.

UPDATE 2

This works. But I am not sure why. :/

cpu_load=$(uptime | cut -d' ' -f 13 | sed '$ s/.$//')
limit=1

send_email(){
echo | mail -s "makroczsk, cpuload $cpu_load is higher than limit $limit!" $email_to
}

echo "cpuload = $cpu_load (${cpu_load%%.*}), limit = $limit"

#[[ (( ${cpu_load%%.*} > $limit )) ]] && send_email
[[ ${cpu_load%%.*} -gt $limit ]] && send_email
bash

1 Answers

  1. Best Answer

    Your approach here is doomed for a number of reasons.

    First, even if you get the syntax correct for arithmetic comparison, i.e. either:

    [ $cpuload -gt $limit ]

    (POSIX shell compatible) or

    [[ $cpuload -gt $limit ]]

    (bash / ksh extended test) or

    (( cpuload > limit ))

    the bash shell only supports integer arithmetic, so you'd need to trim off any trailing decimal first, being mindful of your locale's numeric representation, as mentioned by HuHa.

    Note that when you used [[ $cpuload > $limit ]] that is a syntactically valid comparison in bash, however it will work "strangely", since it compares the RHS and LHS lexicographically, character-by-character. In particular,

    $ [[ 3.0 > 10.0 ]] && echo greater || echo not greater
greater

    because character 3 is lexicographically greater than character 1; whereas

    $ [[ 03.0 > 10.0 ]] && echo greater || echo not greater
not greater

    because character 0 is lexicographically less than character 1. The bottom line is that if you want to do floating point arithmetic in a bash script, you will need an external program such as bc or awk or perl.1


    Second, the uptime output is intended for human readability, not machine parsing. In particular, the time format varies depending on the actual uptime, ex.:

    (before reboot)

    $ uptime
 10:38:50 up 26 days, 12:33,  4 users,  load average: 0.09, 0.04, 0.00

    (after reboot)

    $ uptime
 10:44:37 up 3 min,  1 user,  load average: 0.17, 0.33, 0.16

    Attempting to tokenize it with cut -d' ' is especially fragile, since it relies on exactly how much left-padding each of the fields has: it will fail if the number of days / hours / minutes / users rolls over from single to double digits for example.

    Instead, I'd suggest reading the load average directly from /proc/loadavg - which is where uptime gets it from anyhow, as you can confirm with strace:

    $ strace -etrace=openat uptime 2>&1 | tail -n 3
openat(AT_FDCWD, "/proc/loadavg", O_RDONLY) = 4
 12:49:38 up  2:08,  1 user,  load average: 0.00, 0.01, 0.00
+++ exited with 0 +++

    The format is simple whitespace separated fields that you can easily parse and test with awk for example:

    $ cat /proc/loadavg
0.52 0.58 0.59 1/5 3759

$ limit=10; awk -v limit="$limit" '$1+0 > limit {exit 1}' /proc/loadavg && echo "ok" || echo "overload"
   ok

$ limit=0.5; awk -v limit="$limit" '$1+0 > limit {exit 1}' /proc/loadavg && echo "ok" || echo "overload"
   overload

    Notes:

    1. You could of course switch to a shell that does support non-integer arithmetic, such as ksh or zsh.
    • 11