We have spent the whole module postponing numbers. daily-report.sh already knows how to walk cities, accumulate counters in maps and dispatch subcommands, but when the moment comes to say what percentage of shipments ended in an issue, or what the average amount is, it gives up: we have been truncating cents with ${amount%.*} because, and this is the sentence that sums up the entire lesson, Bash only knows how to do integer arithmetic. This is not a minor limitation or a detail: it shapes how every calculation in a script is written and forces you to know the emergency exits. Here you will see native arithmetic in depth, its traps —including one that breaks date scripts every August— and the external tools for when you really need decimals.

1. Bash does integers only
2. $(( )) and (( )): value versus command
3. Available operators
4. Number bases and the 08 trap
5. declare -i, let and expr
6. Decimals with bc
7. Decimals with awk, and a comparison
8. Percentages and rounding
9. RANDOM, SECONDS and date arithmetic
10. 64-bit limits
11. The complete daily-report.sh

Bash works with 64-bit signed integers, full stop. Division truncates: 7/2 is 3, and -7/2 is -3 (toward zero, not downward). Literals with a decimal point are not even accepted as input. The three practical consequences that govern everything else: for percentages and averages you have to multiply before dividing or the result will be 0; euro amounts are better stored in cents (integers) and formatted at the end; and when you really need decimals in the calculation, you delegate to bc or awk.

They are two different constructs sharing the same internal syntax: n=$(( 3 + 4 )) is an expansion replaced by the value (n holds 7), whereas (( n > 5 )) is a command that produces no output and only sets $? (here, 0 because the comparison is true).

Inside both, variables carry no $, because arithmetic context already knows they are variables:

The $ is only indispensable for positional parameters ($1) and special ones ($#), and for associative array elements with a variable key: (( SHIPMENTS[$c]++ )).

Now the counterintuitive part. As a command, (( )) inverts C's criterion:

It is consistent: in arithmetic, "non-zero" is true; in the shell, success is 0. (( )) translates between both worlds. But that creates a real trap with set -e (you will see it in 05-03), which aborts the script on any failing command: with counter=0, the post-increment in (( counter++ )) evaluates to the previous value, that is 0, so $? is 1 and the script dies. The solutions, in order of preference:

(( ++counter )) (pre-increment: evaluates to 1, code 0), (( counter++ )) || true, or counter=$(( counter + 1 )), which, being an expansion, never fails. Pocket rule: use $(( )) to compute and (( )) for conditions; if you use (( )) to increment under set -e, put the ++ in front or add || true.

Examples: echo $(( 17 % 5 )) gives the remainder 2; max=$(( a > b ? a : b )) keeps the greater of two; and (( errors > 0 && verbose )) && show_detail combines two numeric conditions. Inside (( )) you can safely use < and >, something impossible in [ ] where they would be redirections. That is why to compare numbers, always (( )), leaving [[ ]] for strings and files. It is the same recommendation as in 03-03, now justified.

In arithmetic context, Bash interprets a number's prefix:

The third one is the bomb. A leading zero means octal, and in octal the digits 8 and 9 do not exist, so month="08"; echo $(( month + 1 )) does not print 9: it aborts with bash: 08: value too great for base (error token is "08").

This error shows up exactly where it hurts most: processing dates and times, which naturally come with leading zeros (08 for August, 09 for September, the hour 08:00). A script that worked for eleven months blows up in August. The fix is to force the base with 10#:

Note that here the $ is mandatory: 10#$month textually builds 10#08 before evaluating it. The alternative is to strip the zero with an expansion from 04-04, ${month#0}, although it fails if the value is 00. Apply 10# to every number coming from outside —from date, from a file, from an argument— because you do not control whether it carries leading zeros.

declare -i marks a variable as an integer: any assignment is evaluated as arithmetic.

That last silent behavior is why many style guides advise against it: they prefer normal variables and explicit $(( )), which keeps visible where the computing happens. Use it for obvious accumulators (declare -i total=0) and not for input data.

let "n = 3 + 4" and n=$(expr 3 + 4) are legacy ways of writing n=$(( 3 + 4 )). expr is especially bad: it creates a process per operation, demands spaces around every operator and forces you to escape * as \*; it exists only for compatibility with old shells (08-07). let is a builtin and correct, but (( )) does the same with better syntax. Write (( )) and $(( )); recognize let and expr when you see them in old scripts.

bc is an arbitrary-precision calculator. It reads expressions from standard input and writes the result:

The key points:

• Without scale, division is integer: echo "10/4" | bc gives 2. You have to set scale=N at the start of the expression, or use -l (which loads the math library and sets scale=20); if with -l you only want two decimals, combine bc -l <<< "scale=2; 10/4" or format afterwards with printf '%.2f' (where %% prints a literal %).
• Bash variables are expanded first, so they carry $ and go quoted: bc <<< "scale=2; $a / $b".
• Careful with the decimal separator: bc uses a dot, always. If your data comes with a comma, convert it with ${v/,/.} (04-04).
• bc is not a builtin: every call is a process. Inside a loop over 10,000 lines, that shows.

awk also computes in floating point, and it has one advantage: it can read the file and compute at the same time, in a single pass and a single process. awk -F, 'NR>1 {s += $6; n++} END {printf "%.2f\n", s/n}' shipments.csv returns 26.34, the average amount, with no Bash loop in between.

Selection criterion: integers → $(( )); a one-off decimal calculation → bc; aggregating a whole file → awk. The last one is the star of 06-01, where you will see that many loops from this module collapse into one line.

With integers, the technique is to multiply by 100 before dividing:

To get one decimal without leaving Bash, multiply by 1000 and build the string by hand; and to round to the nearest integer instead of truncating, add half the divisor before dividing:

And the clean version with two decimals, which is the one we will use: printf 'Issues: %.2f%%\n' "$(bc -l <<< "scale=4; $issues * 100 / $total")" prints Issues: 8.59%. Note the scale=4 followed by %.2f: you compute with more precision than needed and round when formatting, which is the correct way to avoid accumulated rounding errors.

RANDOM (seen in 03-02) returns a pseudorandom integer between 0 and 32767 on each read. With the modulo it is bounded to a range, useful for sampling:

With the % operator the low values are ever so slightly favored; for a sampling audit that is irrelevant, for cryptography RANDOM is no use at all (use /dev/urandom).

SECONDS counts the seconds since the shell started or since the last time a value was assigned to it, so SECONDS=0; work; printf 'Processed in %d s\n' "$SECONDS" times a block with nothing else. For finer measurements, date +%s gives the Unix timestamp in seconds (and %s%3N in milliseconds), so start=$(date +%s) followed by $(( $(date +%s) - start )) measures the exact duration.

Date arithmetic. Do not do it by hand: months have different lengths and leap years exist. date -d (GNU) understands relative expressions:

Converting both dates to Unix seconds and subtracting is the universal idiom for "how many days have passed". You will use it in 07-01 to schedule tasks and in 07-03 to delete backups older than N days.

Bash uses 64-bit signed integers: from -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. When you go past that, it overflows silently: echo $(( 9223372036854775807 + 1 )) prints -9223372036854775808. No error, no warning: the number wraps around. In practice you will not hit it adding amounts, but it can show up with nanosecond timestamps or byte sizes multiplied several times. If you suspect a calculation may approach that order of magnitude, use bc, which has arbitrary precision and never overflows.

We add the calculations that were missing. Amounts are accumulated in cents —integers— and only converted to euros when printing:

Output:

And the variation against the previous day, which compares two runs:

Three design decisions worth underlining: amounts live as integers in cents throughout the calculation, bc is invoked once per cell and not inside the reading loop (which processes thousands of lines), and percentage() checks the divisor before dividing, because a division by zero in bc does not abort but does pollute the output.

• Dividing before multiplying. a / b * 100 gives 0 almost always. Always a * 100 / b.
• The octal 08. Every number coming from date or from a file: 10#$n.
• (( counter++ )) with set -e. The post-increment returns code 1 the first time and kills the script. Use ++counter.
• Forgetting scale in bc. Without it the division is integer, just like in Bash, and you will wonder why 10/4 gives 2.
• Not checking the divisor. A day with no shipments makes total equal 0; in $(( )) that aborts with "division by 0".
• Calling bc inside a loop of thousands of iterations. Accumulate in integers and convert at the end, or hand the whole job to awk.
• Tip: store money, times and magnitudes in the smallest integer unit (cents, seconds, bytes). All the arithmetic becomes exact and only the final printf needs decimals.

Exercise 1. Write int_percentage(), which computes the rounded (not truncated) percentage of $1 over $2 using only native arithmetic and returns 0 if the total is zero.

Exercise 2. A script receives an hour in HH format (for example 08 or 19) and must print Delivery hours if it is between 8 and 19 inclusive, and Outside hours otherwise. Write it avoiding the octal trap.

Exercise 3. Compute the average amount per shipment of shipments.csv with two decimals in two ways: accumulating in cents with Bash + bc, and with a single line of awk. Measure how long each one takes with SECONDS.

Solution 1.

The + total / 2 before dividing is the standard integer rounding trick: it adds half a unit of the final result.

Solution 2.

Without the 10#, the input 08 would trigger value too great for base and the script would die every morning at eight. With it, it works equally well with 08, 8 and 19.

Solution 3.

Both give 26.34€. With a few thousand lines both take less than a second, but as the file grows the difference shoots up in awk's favor: a single pass, a single process, native floating point. It is the tool you will start using in 06-01.

Bash computes with 64-bit integers and nothing else: division truncates, decimals are not accepted, and that is why every monetary calculation is done in cents and every percentage multiplies before dividing. $(( )) produces the value and (( )) acts as a command with an inverted exit code —arithmetic zero means failure—, inside both the variables carry no $, and 10#$n saves you from an 08 coming from a date blowing up the script. When you really need decimals, bc -l with its scale solves the one-off calculation and awk solves the whole file; printf %.2f applies the final format. RANDOM, SECONDS and date -d complete the instrument set for sampling, measuring and comparing dates.

This closes Module 4 and, above all, it closes the transformation of daily-report.sh: what in Module 3 was a linear script you had to invoke once per city is today a program with loops, documented functions, counter maps, printf formatting, subcommands dispatched by case and statistics with decimals. It has structure.

What it still does not have is robustness. If the CSV is half-written, if the disk fills up, if someone launches it twice at once, the script will do strange things without saying why. In Module 5 we take that leap: find, xargs, tar and safe temporary files with mktemp (05-01); process and signal management (05-02); set -euo pipefail, trap and debugging with set -x (05-03); real regular expressions with =~ (05-04); file descriptors and here-documents (05-05); and finally the lib/common.sh library we have been promising since 04-02, where your functions will stop living inside a single script and become the shared Veloz Envíos toolkit (05-06).