A bash script begins its option loop with `while getopts "hf:v" opt; do`. Which of h, f and v takes a value, where does bash put that value, and how are `-f out.txt`, `-fout.txt` and `-vf out.txt` each parsed?

## What an optstring actually encodes `getopts` is a shell builtin (POSIX, and present in bash) whose job is to walk the script's arguments one option at a time. Its first argument is the *optstring*: a compact list of the single letters your script accepts. A letter on its own is a boolean flag. A letter followed by a colon takes a value. So `hf:v` declares three options — `-h`, `-f VALUE`, `-v` — and nothing else. The colon binds to the letter *before* it. `hf:v` means `-f` takes a value; it says nothing about `-v`. Reading the colon as belonging to the following letter is the single most common beginner error here. ## The two variables getopts writes Each successful call to getopts writes two things: - the **option letter** into the variable you name as its second argument (`opt` by convention, but any name works); - the **option's value**, if that option was declared with a colon, into `OPTARG`. `OPTARG` is a plain shell variable owned by getopts; it is overwritten on every iteration, so copy it into your own variable inside the matching branch rather than reading it after the loop. ```bash outfile="" verbose=0 while getopts "hf:v" opt; do case $opt in h) usage; exit 0 ;; f) outfile=$OPTARG ;; v) verbose=1 ;; esac done ``` The loop condition is the whole mechanism: getopts returns success while there is another option to report, and returns non-zero when it runs out, which ends the `while`. ## Why $OPTARG and not $2 A hand-rolled parser reaches for `$2` to grab the value after `-f`. That is wrong under getopts for two reasons. First, getopts does not shift the positional parameters as it goes, so after seeing `-f` the value may or may not still be `$2`. Second, the value is not always a separate word at all — `-fout.txt` is legal, and there `$2` is something else entirely. `OPTARG` normalises all of that: whichever spelling the caller used, the value arrives in `OPTARG`. ## The three spellings Given `getopts "vf:" opt`, all of these pass `out.txt` as the value of `-f`: ```bash script -v -f out.txt # separate flag, value as next word script -v -fout.txt # value attached to the option letter script -vf out.txt # bundled flags; the last one takes the next word ``` Bundling (also called clustering) works because getopts consumes one *character* at a time from the current word. In `-vf`, it reports `v` first, then comes back to the same word for `f`, sees that `f` needs a value, and takes the following word. Only the last letter in a bundle may take a value, because everything after a value-taking letter in the same word is read as the value: in `-fv`, `OPTARG` becomes the literal string `v`. ## What this loop does not do for you Two limits are worth knowing from day one. getopts handles **single-character options only** — there is no way to declare `--verbose` in an optstring. And getopts does not remove the options it parsed from the positional parameters; a separate `shift` after the loop is what leaves your script's real arguments in `$1`, `$2`, and so on. ## Common mistakes ```bash # WRONG: value read positionally f) outfile=$2 ;; # WRONG: colon read as belonging to the next letter while getopts "h:fv" opt # this declares -h as taking a value # WRONG: OPTARG read after the loop done echo "$OPTARG" # holds whatever the last value-taking option set, if any ``` Quoting still applies normally: write `outfile=$OPTARG` or `outfile="$OPTARG"` and always quote it when you use it, because a caller can pass a value containing spaces.