In bash, what does `declare -i n` change about later assignments to `n`, and what happens if you then assign a non-numeric value to it?

## Attributes belong to the name Bash variables are strings by default. `declare` (and its synonym `typeset`) lets you attach *attributes* to a name, and those attributes then govern how future assignments to that name behave. This is the key mental model: `declare -i n` does not convert the value that `n` holds right now into an integer type — it marks the name so that everything assigned to it from that point on is put through arithmetic evaluation first. ```bash declare -i n n=2+3 echo "$n" # 5 n=n+1 # no $ needed: bare names are read as variables in arithmetic echo "$n" # 6 ``` Without the attribute, `n=2+3` stores the literal three-character string `2+3`. With it, the right-hand side is evaluated the way an arithmetic context evaluates anything, and the *result* is stored. ## The non-numeric case, precisely This is the part interviewers probe, because the behaviour is surprising and silent: ```bash declare -i n n=foo # foo is an unset variable name -> evaluates to 0 echo "$n" # 0 ``` In arithmetic context a bare identifier is not a literal string; it is a variable reference. `foo` is unset, an unset variable evaluates to 0, and so `n` gets 0. No error, no warning. If a script uses `declare -i` on a variable that receives user input or a value parsed out of a file, garbage silently becomes zero — and a zero can be far more dangerous than an obvious failure when it feeds a `sleep`, a retry count, or an index. A value that is not even a valid expression behaves differently: ```bash declare -i n n=3x # arithmetic syntax error; assignment fails, status non-zero ``` Here bash reports an arithmetic error, `n` keeps its previous value, and the assignment command exits non-zero. Under `set -e` that terminates the script. So `declare -i` gives you two distinct failure modes for bad input: silent zero for a bare word, hard failure for a malformed expression. Neither is validation. If a value must be a number, check it explicitly with a pattern test before you trust it. ## Reading attributes back `declare -p` prints a variable's declaration, attributes included, which is the fastest way to find out what is going on with a name: ```bash declare -ir MAX=100 declare -p MAX # declare -ir MAX="100" ``` The letters after the dash are the attributes. Attributes combine freely: `-i` integer, `-r` readonly, `-x` marked for export, `-a` indexed array, `-A` associative array, `-l` and `-u` for automatic lower/upper casing on assignment. `declare -p` with no name lists everything. ## Removing an attribute Most attributes are removed with a `+` instead of a `-`: ```bash declare -i n declare +i n # n is a plain string variable again ``` The important exception is `-r`. Once a name is readonly — whether via `declare -r` or `readonly` — you cannot clear the attribute, reassign the variable, or `unset` it for the remaining life of that shell. That is not a limitation to work around; it is the point of the attribute. It does, however, have a real practical consequence: a shell library that does `readonly VERSION=1.2` at the top will fail with a readonly-variable error the second time it is sourced into the same shell, so libraries that may be loaded more than once need to guard such declarations rather than declaring unconditionally. ## When to reach for `-i` Honestly, not often. The integer attribute saves a little typing in counters, but the mainstream way to do arithmetic in bash is an explicit arithmetic expression at the point of use, which is visible in the code rather than hidden in a declaration made fifty lines earlier. A reader who has not seen the `declare -i` line cannot explain why `n=2+3` produced 5. The attributes that earn their place in production scripts are `-r` for constants you want protected, and `-a` or `-A` when you need the array shapes. Treat `-i` as something you must be able to *read*, since you will meet it in other people's scripts, more than something you must reach for.