Arguments, Options & Interactive Input

Arguments, Options & Interactive Input

A script that hard-codes its configuration is a script you cannot reuse. Every professional-grade shell tool — from kubectl to aws to your own deployment automation — accepts arguments that change its behavior at call time. In this lesson you will learn the full interface-design toolkit for Bash scripts: positional parameters, the getopts built-in for POSIX-style flags, the canonical usage-function pattern, and the read built-in for prompting a human operator. These four building blocks are enough to build CLIs indistinguishable from standard Unix tools.

Positional Parameters

When Bash invokes a script, every word after the script name lands in a numbered variable. $1 is the first argument, $2 the second, and so on. $0 is the script's own name. $# is the count of arguments. "$@" expands to all arguments as separate quoted words — always prefer this over $* when forwarding arguments, because it preserves whitespace inside individual values.

The ${1:-} form gives you an empty string when the argument is absent, so your -z check fires cleanly. The harder-failing form ${1:?message} makes Bash itself print the message and exit immediately — useful inside functions but can produce confusing output at the top level of a script.

The Usage Function Pattern

Every script that accepts arguments needs a usage function. It documents the interface, is printable on -h/--help, and is called automatically when validation fails. This is the pattern used by HashiCorp, GitHub Actions runner, and most open-source infrastructure tooling:

Notice cat <<EOF — a regular heredoc (not NOWDOC) so that ${SCRIPT_NAME} expands correctly inside the usage text. The usage function is the first thing a new operator reads; make it complete and accurate.

Parsing Flags with getopts

getopts is the POSIX-standard Bash built-in for parsing short options (-v, -t TAG). It handles option bundling (-vn), required arguments, and the -- end-of-options sentinel. It does not handle long options (--verbose) natively; for those, use a manual while/case loop or getopt (the external command with two t's). In practice, most production scripts at large companies use the manual pattern because it handles both short and long forms cleanly.

Handling Long Options with a while/case Loop

For scripts that will be used frequently by humans, long options (--dry-run, --tag) dramatically improve readability. The standard idiom is a manual while true; do case "$1" in ... esac; done loop:

Interactive Input with read

Automated pipelines should never require interactive input — but scripts run by a human operator (provisioning, database migrations, secret rotation) sometimes need a confirmation prompt or a value the script cannot derive itself. The read built-in handles this cleanly.

Key read flags to know: -r disables backslash interpretation (always use it), -p prints a prompt, -s suppresses echoing (passwords), -t N sets a timeout in seconds, and -a reads whitespace-separated words into an array.

Putting It All Together: A Production-Ready Script Skeleton

Combining everything from this lesson produces the skeleton used by real infrastructure scripts at big-tech companies. The pattern is: usage function, argument defaults, flag-parsing loop, positional validation, optional confirmation prompt, then the actual work:

This skeleton — usage function, defaults, flag loop, positional guard, CI-aware confirmation, then work — is the template your team should copy for every new infrastructure script. It behaves correctly whether called by a human, a CI pipeline, or another script.