Variables

A variable is a name holding a piece of text. The shell has no types worth speaking of — everything is a string, and the programs you hand those strings to decide whether they look like numbers.

Assignment looks like every other language. It is the two rules around the assignment that trip people up, and they trip up everyone exactly once.

Assigning and reading

NAME="Ada"
echo $NAME

Set with a bare name, read with a $ in front. That asymmetry is the shell telling you the difference between "the box" and "what's in the box".

Rule one: no spaces around the =

This works:

NAME="Ada"

This does not:

NAME = "Ada"
sh: NAME: command not found

The error tells you exactly what happened. The shell splits a line into words and assumes the first word is a command. NAME=Ada has no spaces, so it is one word containing an =, which the shell recognises as an assignment. NAME = "Ada" is three words, so the shell tried to run a program called NAME with the arguments = and Ada.

Once you see it that way it stops being an arbitrary rule. There is no way the shell could allow the spaces without losing the ability to pass = as an argument.

Rule two: quote the value

MSG=Hello World

fails too, and for the same reason: the shell sees MSG=Hello (an assignment) followed by World (a command to run with that variable set). A variable holds one value, so anything containing a space has to be quoted.

MSG="Hello World"

Quoting when you read, too

Reading a variable is where quoting really earns its keep. Compare:

FILE="my report.txt"
rm $FILE       # runs: rm my report.txt   — two files, both wrong
rm "$FILE"     # runs: rm "my report.txt" — one file, correct

After substituting the value, the shell splits the result into words again. Without quotes, a value containing a space becomes two arguments. This is the single most common bug in shell scripts, and it is invisible until someone's filename has a space in it — which, on any machine touched by a human, is eventually.

The habit worth building now: write "$VAR", always, unless you have a specific reason not to.

Curly braces disambiguate

The shell reads a variable name greedily — as far as the characters allow.

FOO=sun
echo $fooshine     # empty: there is no variable "fooshine"
echo ${FOO}shine   # sunshine

The braces say where the name stops. You will mostly see them used exactly like this, gluing a variable to text that follows it. In the next lessons they pick up some genuinely powerful extra behaviour.

Reading input

read takes a line from standard input and puts it in a variable:

#!/bin/sh
printf "What is your name? "
read NAME
echo "Hello, $NAME"

Note printf rather than echo -n. Suppressing the trailing newline is the one thing echo does differently on every shell: echo -n works on bash, echo "...\c" works on dash and the original Bourne shell, and each prints the other's syntax literally. printf behaves the same everywhere, which is why portable scripts use it whenever the output is anything more than a plain line of text.

Next up: quoting and wildcards — the rest of what happens to a line between you pressing enter and a program actually running.