Script Arguments and User Input

Build the mental model

When you run a script with arguments, like `./greet.sh alice bob`, bash makes them available inside the script as positional parameters: `$1` is the first argument, `$2` the second, and so on up through `$9` (beyond that you need `${10}`, with braces, since `$10` would be parsed as `$1` followed by a literal `0`), while `$#` tells you how many arguments were passed in total. `$@` and `$*` both nominally mean 'all the arguments,' but they diverge sharply depending on whether you quote them. Unquoted, both word-split the same way and lose any internal structure. Quoted, they behave completely differently: `"$@"` expands to each argument as its own separate, correctly preserved word — even ones containing spaces — while `"$*"` joins every argument into a single combined string using the first character of `$IFS` (a space, by default) as the separator. This is why `"$@"` is almost always the right choice when looping over arguments one at a time. For input that isn't handed in ahead of time as arguments, the `read` builtin pauses execution and stores a line of typed (or piped) input into a variable, which is what lets a script prompt a user interactively. And because arguments and variables are often optional, the `${1:-default}` expansion pattern supplies a fallback value whenever the referenced argument or variable is unset or empty, so the script doesn't crash or silently use a blank string.

Connect it to a real scenario

A backup script might accept a target directory as its first argument but fall back to a sensible default if the user doesn't supply one: `target=${1:-/var/backups}` means the script still works correctly even when invoked with zero arguments. Now suppose that same script also needs to loop over a list of filenames passed as further arguments, some of which — like `"charlie brown"` in the lesson's own example — contain spaces. Looping with unquoted `$*` (or quoted `"$*"`) collapses everything into pieces or a single glued-together string, splitting `"charlie brown"` into two separate words `charlie` and `brown`, exactly as the example output shows. Looping with quoted `"$@"` instead preserves each original argument intact, so `"charlie brown"` stays one item. The same care applies to `read`: capturing a line into a variable and then using it unquoted downstream reintroduces the exact word-splitting risk covered in the previous lesson.

• $1, $2, ... are positional parameters; $# is the argument count
• Loop over arguments with "$@" (quoted) — it preserves each argument as a separate word even if it contains spaces, unlike $* or unquoted $@
• ${1:-default} supplies a fallback value when an argument or variable is unset, and read captures a line of interactive input

Try the working example

#!/usr/bin/env bash
# Simulate command-line arguments using "set --" (in real use these
# would come from: ./script.sh alice bob "charlie brown")
set -- alice bob "charlie brown"

echo "Argument count: $#"
echo "First argument: $1"
echo "Second argument: $2"

echo 'Looping with unquoted $*:'
for name in $*; do
  echo "  name -> $name"
done

echo 'Looping with quoted "$@":'
for name in "$@"; do
  echo "  name -> $name"
done

echo "Enter your favorite language:"
read -r favorite <<< "bash"
echo "You picked: $favorite"

greeting=${4:-"stranger"}
echo "Hello, $greeting"

Running this script prints:

Argument count: 3
First argument: alice
Second argument: bob
Looping with unquoted $*:
  name -> alice
  name -> bob
  name -> charlie
  name -> brown
Looping with quoted "$@":
  name -> alice
  name -> bob
  name -> charlie brown
Enter your favorite language:
You picked: bash
Hello, stranger

GNU Bash Reference Manual — Special Parameters — Bash / Shell Scripting