A bash backup script sets `month=$(date +%m)` and then computes `$(( month + 1 ))`. It works most of the year but in August fails with `value too great for base (error token is "08")`. What happened, and how do you fix it?

## Numeric literals in arithmetic context Bash's arithmetic evaluator recognises constants exactly the way C does, plus one extension: - plain digits — decimal: `42` - leading `0` — **octal**: `010` is 8 - leading `0x` or `0X` — hexadecimal: `0x1f` is 31 - `base#digits` — any base from 2 to 64: `2#1011` is 11, `16#ff` is 255, `10#0075` is 75 The octal rule is inherited from C and predates every shell script that ever parsed a timestamp. It is harmless for hand-written constants — nobody writes `010` meaning ten — but it is a landmine for values that arrive zero-padded from elsewhere. ```bash echo $(( 010 )) # 8, not 10 echo $(( 0x10 )) # 16 echo $(( 07 + 1 )) # 8 -- valid octal, silently wrong if you meant seven echo $(( 08 + 1 )) # error: value too great for base (error token is "08") ``` ## Why this bug is seasonal `date +%m` and `date +%d` zero-pad to two digits, so eight months and days of the year produce a string bash reads as octal. Months `01` through `07` and days `01` through `07` are *valid* octal and evaluate to the same number as decimal — which is why the script appears to work. Only `08` and `09` are invalid, so the failure lands on exactly two months and two days per month. A script written in March and deployed in March passes every test until August. Worse than the loud error is the quiet version: not every zero-padded value contains an 8 or 9. A three-digit padded counter like `017` evaluates to 15 with no error at all, which is a wrong answer rather than a crash. ## The fix The canonical repair is the base prefix: ```bash month=$(date +%m) next=$(( 10#$month + 1 )) ``` `10#` says "interpret the following digits in base 10", which makes the leading zero meaningless. It is safe when the value is not padded — `10#7` is just 7 — so you can apply it unconditionally to anything coming from `date`, a filename, an API response, or a config file. One subtlety worth stating in an interview: this is a rare arithmetic context where you **must** write `$month` rather than the bare name `month`, because the base prefix has to be textually attached to the digits. `$(( 10#month ))` is a syntax error, since `month` is not a digit string. A corollary is that if the variable is empty, `$(( 10#$month ))` becomes `$(( 10# ))` and errors — so guard or default the value if it might be unset. Other approaches and why they are weaker: ```bash next=$(( ${month#0} + 1 )) # strips ONE leading zero; "00" becomes empty and errors next=$(( ${month##+(0)} + 1 )) # needs shopt -s extglob, and "00" still empties out printf -v m '%d' "$month" # printf %d also parses 08 as octal on some builds next=$(( $(( 10#$month )) + 1 )) # works but is needless nesting ``` The `${month#0}` trick is common in the wild and is a trap of its own: a value of `00` becomes the empty string, and `$(( + 1 ))` errors. `10#` handles `00` correctly, yielding 0. ## Getting the padding back Arithmetic strips the padding, so if the output must stay two digits, format it explicitly: ```bash printf -v next_month '%02d' "$(( 10#$month % 12 + 1 ))" echo "$next_month" # 09 in August, 01 in December ``` `printf -v` assigns directly into the variable without a subshell, which is both faster and cleaner than `next=$(printf '%02d' ...)`. ## Where else it shows up Anything zero-padded and arithmetic-bound: build numbers (`build=007`), zero-padded partition or disk indices, `%H`/`%M`/`%S` time components in a duration calculation, ID fields from a fixed-width export, and version segments parsed out of a tag. The habit worth forming is that **any string that came from outside the script and is about to enter `$(( ))` gets `10#`** unless you specifically want the other bases.