In a bash script, the line `count = 5` fails with `count: command not found`. Why does bash reject spaces around `=` in an assignment, and what are the correct forms when the value itself contains spaces?

## Bash parses words, not statements Most languages have a grammar in which `=` is an operator and surrounding whitespace is irrelevant. Bash does not. A bash line is first split into *words* on unquoted whitespace, and the shell then decides what kind of command it is looking at based on the shape of those words. The rule for a variable assignment is narrow: the word must match `NAME=word`, where `NAME` is a valid identifier (letters, digits and underscores, not starting with a digit) and the `=` is part of the same word. Write `count = 5` and you have produced three words: `count`, `=`, and `5`. None of them is an assignment, so bash falls back to the ordinary rule — the first word is a command name and the rest are its arguments. There is no program called `count` on a typical system, so you get `count: command not found` with exit status 127. ## The correct forms ```bash count=5 # integer-looking value, one word, fine unquoted msg="hello world" # value has a space, so it must be quoted path=/usr/local/bin # slashes are fine, no quoting needed empty= # sets empty to the empty string (it IS set) ``` The right-hand side of an assignment is a single word after quote removal. `msg=hello world` does not assign two words to `msg`; it assigns `hello` to `msg` *for the duration of the command `world`*, and then tries to run `world`. Quoting is what keeps the value together. One thing that surprises people coming from other shells or languages: you never put a `$` on the left. `$count=5` expands `count` first and then tries to run the resulting text as a command. The `$` is for *reading* a variable; a bare name is for *writing* it. ## The three near misses, precisely | Line | What bash actually does | |---|---| | `count=5` | Assigns `5` to `count` in the current shell | | `count = 5` | Runs the command `count` with arguments `=` and `5` | | `count =5` | Runs the command `count` with the argument `=5` | | `count= 5` | Sets `count` to empty for one command, then tries to run `5` | That last row is the interesting one, because it is not an error in the parser at all — it is the legal *prefix assignment* form, where one or more `NAME=value` words in front of a command apply to that command only. `count= 5` is a perfectly well-formed command line; it just names a command, `5`, that does not exist. ## Why this trips people up in reviews The failure mode is quiet. Because the shell sees a command rather than an assignment, the script keeps going with the variable unset, and the symptom shows up much later as an empty expansion — a `rm -rf "$prefix/data"` that becomes `rm -rf /data`, or a curl to `https:///api`. If the script runs with `set -u`, the later read of the unset variable at least aborts; without it, an empty value silently propagates. This is exactly the class of bug linters catch cheaply, and ShellCheck flags the pattern rather than waiting for runtime. ## Assignment versus other things that look like it The same no-spaces rule applies anywhere bash expects a `NAME=value` word, and the error messages differ: ```bash export PATH = /usr/bin # export: `=': not a valid identifier export PATH=/usr/bin # correct declare -i n = 5 # declare: `=': not a valid identifier declare -i n=5 # correct ``` `export`, `declare`, `readonly` and `local` are builtins that take `NAME` or `NAME=value` *arguments*. Splitting the argument with spaces hands them three separate arguments, and `=` on its own is not a legal identifier. ## Set versus unset versus empty Finally, `empty=` and `unset empty` are not the same thing. After `empty=`, the variable exists and holds the empty string; after `unset empty`, the name is gone. Under `set -u` the first is a perfectly valid read and the second aborts the script, and the parameter-expansion operators that distinguish the two cases exist precisely because the distinction is real.