Command-Line Arguments and getopts
Every Bash script can accept input from the command line in the form of positional parameters. When you run ./deploy.sh production --force, Bash makes each whitespace-separated token available inside the script through special variables: $0 is the script name, $1 is the first argument, $2 the second, and so on. $# holds the total argument count, and $@ / $* expand to the full argument list (with important differences when quoted). Handling these correctly is the foundation of writing scripts that behave like real command-line tools rather than fragile one-off hacks.
Cricket analogy: Running ./deploy.sh production --force is like a captain reading out the day's instructions: $0 is the match itself, $1 is the venue ('production'), $2 is the tactic ('--force'), $# is the total number of instructions given, and $@/$* are the full team briefing read back word by word or as one announcement.
Positional Parameters and $@ vs $*
"$@" expands each positional parameter as a separate quoted word, preserving arguments that contain spaces — this is almost always what you want when forwarding arguments to another command. "$*" instead joins all parameters into a single string separated by the first character of IFS (a space by default). Unquoted $@ and $* behave identically and are both dangerous because the shell re-splits them on whitespace and performs globbing, which can silently mangle filenames containing spaces or wildcards. The shift builtin removes $1 and renumbers the rest down by one, which is the standard idiom for looping through arguments one at a time.
Cricket analogy: "$@" is like announcing each player's name separately even if a name has a space ('Ravindra Jadeja'), which matters when passing the full XI to another list; "$*" merges everyone into one long announcement string, and unquoted versions risk splitting names mid-word, mangling the roster.
#!/usr/bin/env bash
set -euo pipefail
echo "Script name : $0"
echo "Arg count : $#"
echo "All args : $*"
while [[ $# -gt 0 ]]; do
echo "Processing: $1"
shift
done
# Forwarding arguments safely to another command
run_backup() {
tar czf "$1" "${@:2}"
}
run_backup /backups/etc.tar.gz /etc/nginx /etc/sshParsing Options with getopts
For scripts that accept flags like -v, -o file, or -h, hand-rolling a parser with if/elif chains gets messy fast. The getopts builtin (POSIX-compliant, available in every Bash installation) parses short options in a single pass. You define an option string such as "vo:h" where a letter followed by a colon means that option requires an argument. getopts sets $OPTARG to the option's argument and $OPTIND to the index of the next unparsed argument, which you use with shift $((OPTIND - 1)) to discard the parsed options and leave only the remaining positional arguments.
Cricket analogy: getopts is like a scorer parsing shorthand flags for a match report (-v for venue, -o for opposition with a name required), setting $OPTARG to the opposition's name and $OPTIND to the next unparsed item; shift $((OPTIND - 1)) then discards the parsed flags, leaving just the remaining match notes.
#!/usr/bin/env bash
set -euo pipefail
verbose=false
outfile=""
usage() {
echo "Usage: $0 [-v] [-o outfile] <input>" >&2
exit 1
}
while getopts ":vo:h" opt; do
case "$opt" in
v) verbose=true ;;
o) outfile="$OPTARG" ;;
h) usage ;;
\?) echo "Invalid option: -$OPTARG" >&2; usage ;;
:) echo "Option -$OPTARG requires an argument" >&2; usage ;;
esac
done
shift $((OPTIND - 1))
input="${1:-}"
[[ -z "$input" ]] && usage
$verbose && echo "Reading from: $input, writing to: ${outfile:-stdout}"getopts only handles single-dash short options natively (e.g. -v, -o). For GNU-style long options like --verbose or --output=file, most system utilities rely on the external getopt(1) command (from util-linux) which supports both short and long forms, or scripts implement a manual case/while loop over "$@" matching patterns like --output=*). Many production Bash scripts use getopts for short flags and a manual loop for long ones, since a pure-Bash long-option parser via getopts alone does not exist.
A leading colon in the option string (e.g. ":vo:h") switches getopts into 'silent error reporting' mode, where invalid options and missing arguments are reported via $opt being set to ? or : instead of getopts printing its own error message. Omitting the leading colon causes getopts to print terse built-in errors that you cannot customize — always start your option string with a colon in production scripts so you control the error messages.
Validating and Defaulting Arguments
Robust scripts never assume an argument was supplied. Use parameter expansion defaults such as ${1:-default} to substitute a fallback value, or ${VAR:?error message} to abort with a clear message when a required variable is unset or empty. Combining getopts for flags with explicit checks on the remaining positional parameters (via $# and case statements) produces scripts that fail fast with actionable errors instead of proceeding with empty or wrong values, which is especially important in scripts run non-interactively from cron or CI pipelines.
Cricket analogy: ${1:-default} is like fielding a default position if the captain didn't specify one, while ${VAR:?error message} is like aborting the toss with a clear announcement if the pitch report is missing; combining getopts with $# checks means an automated scoring script fails fast instead of recording a phantom match.
- $0 is the script name; $1..$9 (and ${10}, etc.) are positional args; $# is the count.
- Always quote "$@" when forwarding arguments — it preserves word boundaries; unquoted $@/$* trigger word-splitting and globbing.
shiftdrops $1 and renumbers the rest, enabling simple while-loops over arguments.- getopts parses short options (e.g. -v, -o arg) in a single pass; set $OPTIND-based shift afterward to reach remaining positional args.
- Prefix the getopts option string with a colon to get silent error handling you can customize via the ? and : cases.
- For long GNU-style --options, use the external getopt(1) or a manual case/while parser — getopts alone doesn't support them.
Practice what you learned
1. In a Bash script, which variable holds the total number of positional arguments passed to the script?
2. Why is "$@" generally preferred over unquoted $@ when forwarding arguments to another command?
3. Given the getopts option string ":vo:h", what does the colon immediately after 'o' mean?
4. After a getopts loop finishes processing flags, what is the correct idiom to remove the parsed options and leave only remaining positional arguments?
5. Which statement about getopts is accurate?
Was this page helpful?
You May Also Like
Writing Your First Bash Script
Get hands-on with the anatomy of a Bash script — shebang, permissions, execution, comments, and structuring commands into a reusable, repeatable tool.
Variables and Quoting in Bash
Understand how Bash stores and expands variables, and why quoting rules — single, double, and unquoted — are critical to writing scripts that don't break on real-world input.
Exit Codes and Error Handling
Understand how every command reports success or failure through its exit status, and how to build scripts that detect and respond to errors reliably.
Functions in Bash
Learn how to define reusable Bash functions, pass arguments and return values, manage variable scope with local, and organize larger scripts around them.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics