Watch a disk alert fail at 100 percent

short · 25 min · Objective 4.2

Task

Reproduce the string-versus-numeric comparison bug in the exact form that matters: a disk alert that works at 95% and silently stops working at 100%. Then map the operator families and confirm where <= actually lives.

Steps

  1. Write the broken check: used=100; if [[ "$used" > "90" ]]; then echo ALERT; fi. Confirm it does NOT alert, and explain why "100" sorts before "90".
  2. Run the same check with used=95 and confirm it DOES alert. This is the trap: it works for most values and fails at the one that matters most.
  3. Fix it with the numeric operator: [[ "$used" -gt 90 ]], and confirm it alerts correctly at both 95 and 100.
  4. Show the reverse failure is loud, not silent: [[ "abc" -gt 5 ]] errors, where the string-comparison bug did not.
  5. Confirm <= is arithmetic, not a string operator: [[ 5 <= 9 ]] is a syntax error, while (( 5 <= 9 )) works. Explain the mapping.
  6. Demonstrate return codes: run a command that fails, capture $? immediately into a variable, and show that testing $? one line too late tests the echo in between.
  7. Recognise exit 137: run bash -c 'kill -9 $$' in a subshell and read the 137 that 128+9 produces.

Verify

cd ~/lab-ops
used=100; [[ "$used" > "90" ]] && echo "string: alerts" || echo "string: SILENT at 100"
used=100; [[ "$used" -gt 90 ]] && echo "numeric: alerts correctly"
( bash -c 'kill -9 $$'; echo "exit $?" ) | tail -1     # 137

The first line printing "SILENT at 100" is the whole lab: the wrong operator family gives a wrong answer, not an error, and it fails precisely when the disk is fullest.

Notes

The families do not mix. -gt -lt -eq compare numbers; > < = == compare strings; <= >= are arithmetic and live only in (( )). CompTIA's own objective list prints the regex operator as "= ~" and inequality as "! =" with spaces -- both are typos, and a space breaks either.