Bash Fundamentals

Bash is the GNU Bourne-Again Shell: a command interpreter that reads lines you type or a script you hand it, expands them, and runs the resulting commands. It is the default interactive shell for the root and human accounts on most Debian and Ubuntu installs, and it is what you land in when you SSH into a box. Its job is narrow and exact — parse a line into words, perform a fixed sequence of expansions on those words, find the command, and execute it — and almost every surprising thing a shell does is explained by getting that sequence right or wrong.

The operational consequence is that the shell is not a programming language you reason about by intuition; it is a text processor with sharp edges. An unquoted variable that happens to contain a space becomes two arguments. A glob that matches nothing is passed through literally by default. On Debian and Ubuntu, /bin/sh is dash, not Bash — so a script that works at your prompt can fail under sh script.sh or in a #!/bin/sh cron job because the Bash-only features it relied on do not exist there.

Command Parsing and Word Splitting

When Bash reads a command line it splits it into words on whitespace, then performs expansions, then splits the results of most expansions again on the characters in IFS (space, tab, newline by default). That second split is the one that bites people: a variable holding two words expands into two separate arguments unless you quote it. The fix is mechanical and absolute — wrap every variable and command substitution in double quotes unless you have a specific reason to want splitting.

file="my report.txt"
# Wrong: rm sees two arguments, "my" and "report.txt"
rm $file
# Right: rm sees one argument
rm "$file"

Globbing is the other half of word handling. *, ?, and [...] are expanded by the shell against the filesystem before the command runs — the command never sees the pattern, only the filenames it matched. If a pattern matches nothing, Bash passes the literal pattern through unchanged, so a loop over *.log in an empty directory runs once with the string *.log. Setting shopt -s nullglob makes a non-matching pattern expand to nothing instead, which is almost always what a script wants.

Quoting Rules

Bash has three quoting forms and they are not interchangeable. Single quotes are literal — nothing inside them is special, not even $. Double quotes suppress word splitting and globbing but still perform parameter, command, and arithmetic expansion, so "$var" is interpolated while spaces in its value are preserved. A backslash escapes the single following character. The default rule for production scripts is double quotes around every expansion and single quotes for any string you want kept verbatim.

Form	Variables expand?	Splitting / globbing?	Use for
'single'	No	No	Literal strings, regex, sed scripts
"double"	Yes	No	Values that may contain spaces — the default
unquoted	Yes	Yes	Only when you deliberately want a list to split

Variables, Environment, and Quoting Scope

A shell variable lives only in the current shell. Marking it with export places it in the environment, which is the copy a process passes to every child it spawns — that is how PATH, HOME, and your custom settings reach the programs you launch. Children cannot write back to the parent's environment, so a variable set inside a subshell or a piped command vanishes when that subshell exits. This is why cmd | while read x; do count=$((count+1)); done leaves count at zero in Bash: the while runs in a subshell on the right of the pipe.

GREETING="hello"      # shell variable, this shell only
export EDITOR=/usr/bin/vim  # now inherited by child processes
env | grep EDITOR      # visible; GREETING is not

Names are case-sensitive and conventionally uppercase for environment variables, lowercase for script-local ones, which keeps your variables from colliding with the dozens the system already exports. Assignment takes no spaces around the = — x = 1 tries to run a command called x. Reference a value with $name or, when the name butts against other characters, the unambiguous ${name}.

Startup Files and Login vs Interactive Shells

Bash reads different files depending on how it starts, and getting this wrong is why "my PATH works in the terminal but not over SSH" happens. A login shell (an SSH session, or bash -l) reads /etc/profile then the first it finds of ~/.bash_profile, ~/.bash_login, ~/.profile. A non-login interactive shell (a new terminal tab inside an existing session) reads /etc/bash.bashrc and ~/.bashrc. A non-interactive shell running a script reads neither, unless BASH_ENV points at a file.

On Debian and Ubuntu the convention is to put everything in ~/.bashrc and have ~/.profile source it, so both kinds of shell pick up the same configuration. Put PATH edits and exported variables in ~/.profile or ~/.bash_profile (they need to apply once at login and be inherited); put aliases, the prompt, and shell options in ~/.bashrc (they are per-interactive-shell and are not inherited). On Red Hat systems the equivalent system file is /etc/bashrc rather than /etc/bash.bashrc, and /etc/profile.d/*.sh is the standard drop-in directory on both families.

Exit Status and Command Sequencing

Every command returns an integer exit status: 0 is success, anything from 1 to 255 is a failure, and the most recent value is in $?. The shell is built on this convention. && runs the next command only if the previous one succeeded; || runs it only on failure; a bare ; runs the next command regardless. In a pipeline, $? is the status of the last command only, so grep pattern file | sort reports success even if grep found nothing — unless you set pipefail.

set -o pipefail
mkdir -p /opt/app && cd /opt/app || { echo "setup failed" >&2; exit 1; }
# && chains the steps; || handles the first failure