EX200 Create simple shell scripts Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Using 'local' keyword for variable declarations inside functions.

  Why this is correct

  Declaring variables with `local` inside a function constrains their scope to that function and its called subshells, preventing them from leaking into and clobbering global variables. This avoids hard-to-trace side effects, strengthens reusability and recursion, and is a core principle of writing clean, modular Bash functions.

• ✓

  Always quoting variable expansions with double quotes.

  Why this is correct

  Always surrounding variable expansions with double quotes forces the shell to treat the expansion as a single word, preventing word splitting on spaces, tabs, or newlines and suppressing unintended glob expansion. This is especially critical for arbitrary file names, user input, or arguments that might contain wildcards, and it also preserves empty values as explicit empty arguments.

• ✓

  Using [[ $var =~ regex ]] for pattern matching.

  Why this is correct

  The `[[` compound command, when combined with `=~`, applies extended regular expression matching without subjecting the pattern to word splitting or pathname expansion, making behavior far more predictable than `[` or `grep`-based tests. It also captures matched substrings into `BASH_REMATCH`, giving it a level of power and clarity that traditional test commands or `expr` cannot match.

• ✗

  Using 'set -e' to exit on non-zero exit codes.

  Why it's wrong here

  Relying on `set -e` as a safety net is widely discouraged because it only triggers on the exit status of the entire pipeline's last command, not on every intermediate failure, and it is silently suppressed inside conditionals, negated commands, and compound predicates. A command that fails but is part of a fallback like `cmd || fallback` won't abort, while certain benign failures in unrelated functions can cause the whole script to terminate, creating brittle and confusing runtime behavior.

• ✗

  Using the 'source' command instead of '.' for readability.

  Why it's wrong here

  Although `source` is a convenient builtin that is slightly more readable than a simple dot, it is a Bashism and not required for any POSIX-compliant shell; `.` is the standard portable command and does exactly the same job. Preferring `source` over `.` adds no functional benefit and reduces portability of your scripts to minimal dash-like environments, so it is not an objectively 'recommended practice' over the dot notation.

Go deeper

Related to this question