Bash Scripting Fundamentals

Concept Overview Variables in bash are assigned with name=value — critically, with no spaces around the =. name = value (with spaces) is not an assignment at all; bash parses it as trying to run a command called name with arguments = and value, which fails with a confusing 'command not found' error. This single spacing rule trips up more beginners than almost anything else in bash.

You read a variable's value by prefixing it with $, either as $name or, more safely, ${name} — the braces matter whenever the variable name is immediately followed by other characters that could otherwise be read as part of the name, for example ${name}_backup versus the ambiguous $name_backup (which bash would try to read as a variable literally named name_backup). Using ${} consistently is a good habit even when it isn't strictly required.

Quoting matters enormously. Double quotes ("$name") still allow variable expansion but prevent word splitting and glob expansion — if $name contains spaces, "$name" preserves it as one value, while unquoted $name lets the shell split it into multiple words wherever whitespace appears, often breaking commands that assumed a single argument. Single quotes ('$name') suppress expansion entirely — the text is treated completely literally, dollar signs and all. The practical rule: quote every variable expansion with double quotes unless you specifically need word splitting to happen, which is rare.

Variables assigned without export are local to the current shell/script — a child process (like a script you call from another script) won't see them. export NAME=value makes a variable part of the environment passed to child processes, which is how environment variables like PATH or HOME work; a plain variable, by contrast, exists only in the current shell session.

Command substitution captures a command's output into a variable: result=$(ls /tmp) runs ls /tmp and assigns its output to result. The $(...) syntax is preferred over the older backtick syntax (`ls /tmp`) because it nests cleanly — you can put a $(...) inside another $(...) without the escaping headaches backticks require. Arithmetic uses $(( )): count=$((count + 1)) performs integer arithmetic, which plain string concatenation with + would not.

Concept Overview When a script is invoked with arguments (./deploy.sh production v2.1), bash makes them available inside the script as positional parameters. $1 is the first argument, $2 the second, and so on; $0 is the script's own name/path, not the first argument — a common off-by-one mistake for people coming from languages where argv[0] is more obviously 'the first real argument.'

$# holds the count of arguments passed, which is what you check before using an argument, to give a helpful usage message instead of a cryptic failure: if [ $# -lt 2 ]; then echo "Usage: $0 <env> <version>"; exit 1; fi. $@ expands to all arguments, and when quoted as "$@" it expands each argument as a separate, correctly-quoted word — this is the form you want when forwarding arguments to another command, because it preserves arguments that themselves contain spaces. $* is similar but joins everything into a single string, which is almost never what you want when forwarding arguments, since it collapses the individual-word boundaries. As a rule: use "$@" to pass arguments through faithfully, and reach for $* only when you deliberately want one combined string (for logging a command line, for instance).

shift removes $1 and renumbers the rest down by one — $2 becomes the new $1, and so on. This is how you process a variable number of arguments in a loop: while [ $# -gt 0 ]; do process "$1"; shift; done walks through every argument one at a time regardless of how many were passed.

Every command in Unix, including your own script, communicates success or failure through a numeric exit code — 0 means success, any nonzero value (1-255) means some kind of failure, and different nonzero values can convey different failure reasons if you choose to use them that way. $? immediately after a command holds that command's exit code, which is how you check whether something succeeded: if [ $? -eq 0 ]; then echo ok; fi — though in practice if command; then ... fi checking the command's exit status directly is more idiomatic than capturing $? into an intermediate check. exit N at the end of your own script sets its exit code for whatever called it; a script with no explicit exit returns the exit code of its last executed command. This matters enormously in automation — a CI pipeline, a cron job, or another script calling yours relies entirely on the exit code to decide whether to proceed, retry, or alert, regardless of what text was printed.