A bash associative array `declare -A opts` may legitimately hold empty-string values. How do you test whether a given key is present, as opposed to present-but-empty?

## Two different questions "Is this key in the map?" and "does this key have a non-empty value?" are different questions, and bash's most reachable test answers the second one. In a map used as a lookup table this rarely matters, because every key you store has a real value. It matters as soon as the empty string is meaningful — a parsed config where `LOG_FILE=` means "deliberately blank", a set of seen items where the value is a placeholder, a flags map where presence is the whole signal. ```bash declare -A opts opts[verbose]='' # key exists, value empty [[ -n ${opts[verbose]} ]] # FALSE - asks about the value [[ -v opts[verbose] ]] # TRUE - asks about the key [[ -v opts[missing] ]] # FALSE - key really is absent ``` ## The `-v` operator `-v` is a unary test that reports whether a *name* is set. Bash 4.2 introduced it for ordinary variables; bash 4.3 extended it to understand array subscripts, which is the form you need here. Note that the operand is written bare — `[[ -v opts[verbose] ]]`, not `[[ -v ${opts[verbose]} ]]`. You are naming the thing to test, not expanding it. Passing the expansion instead would hand `-v` the *value* as a name, which is a different (and usually meaningless) test. Because `[[ ]]` performs no word splitting or pathname expansion on its operands, the subscript needs no quoting even when it holds a variable: `[[ -v opts[$key] ]]` is safe. ## The pre-4.3 alternative If you are targeting older bash 4.x, use the set-versus-unset form of parameter expansion. `${var+word}` — the version *without* a colon — substitutes `word` only when the variable is set, regardless of whether it is empty; the colon form `${var:+word}` additionally requires a non-empty value. Applied to a subscript: ```bash if [[ -n ${opts[verbose]+x} ]]; then echo 'key exists (possibly empty)' fi ``` The `x` is arbitrary — any non-empty placeholder works. This idiom predates `-v` and still appears widely in scripts that must run on a range of bash versions. ## Removing a key, and the quoting trap Deletion is `unset`, and it comes with a real hazard: ```bash unset 'opts[verbose]' # correct - quoted unset opts[verbose] # risky - the word is a glob ``` Outside `[[ ]]`, the word `opts[verbose]` is an ordinary command argument, and `[...]` is a pathname-expansion bracket expression. If the current directory happens to contain a file matching that pattern — `optsv`, `optse`, `optsr` and so on — the shell replaces the argument with that filename and `unset` operates on the wrong name, silently leaving your key in place. Quoting the argument stops the expansion. ShellCheck warns about unquoted `unset` arguments for exactly this reason. The same reasoning applies to `unset 'opts[$key]'`, where the key's own contents could contain glob characters. Also note the difference between deleting a key and emptying it: `unset 'opts[k]'` makes `[[ -v opts[k] ]]` false, while `opts[k]=''` leaves it true. ## Wiping the whole map `unset opts` removes the variable entirely, including its `-A` attribute — so a later `opts[k]=v` would recreate it as an *indexed* array with the arithmetic-subscript behaviour that entails. If you want an empty map that is still a map, re-declare it: `unset opts; declare -A opts`, or assign `opts=()`, which empties the array while keeping the associative attribute. ## What good looks like A script that treats presence as data should say so in the test it writes. Reaching for `-v` (or the `+x` form) instead of `-n` on the value is a small tell that the author has thought about what an empty value means in their data model, which is the point the question is really probing.