Shell Scripting

**Judgement:** This skill is a strong, practical guide for writing robust bash scripts, well-suited for production-style automation on Linux and macOS when bash is available. It offers a good default template, strong argument parsing examples, sensible logging patterns, safe temp-file handling, and pragmatic guidance on parallelism and process management. **Notable strengths** - Encourages `set -euo pipefail`, consistent quoting, and `trap cleanup EXIT`, which significantly reduce common scripting bugs. - Provides a reusable, realistic script skeleton with `usage`, `die`, `log`, `debug`, and argument parsing including `--help`. - Covers real-world topics: retries with backoff, lock files to prevent concurrent runs, parallelism with `xargs -P` and GNU parallel, process supervision and timeouts. - Distinguishes some GNU vs BSD/macOS differences (`sed`, `date`, `stat`, `readlink`) and highlights POSIX-safe patterns (e.g., `printf`, `$()` vs backticks). **Key risks / limitations** - **Bash-specific focus:** The core template and many patterns rely on bash features (`[[ ]]`, arrays, `BASH_SOURCE`, `readonly` semantics). Despite some POSIX notes, these examples are *not* portable to `/bin/sh` on all systems; they are primarily **bash scripting** patterns. - **`set -e` semantics:** While `set -euo pipefail` is a good default, `set -e` has subtle edge cases (in subshells, `if`/`while` conditions, certain pipelines). The skill shows some mitigation (temporary `set +e` and manual exit-code checks) but does not fully explain the pitfalls, so generated scripts might sometimes behave unexpectedly on failures in more complex control flows. - **Portability gaps:** Some examples assume tools or flags that are not universally available: - `grep -P` is used for config-file validation but is not present by default on macOS (contradicting the earlier warning about `grep -P`). - `timeout` and GNU-specific options, and GNU parallel, may be missing on minimal or BSD-centric systems, requiring fallbacks. - **Config sourcing safety:** The config-file example uses a regex check to avoid obviously dangerous content before `source`-ing, but `source` is always a potential code-injection vector if the file is not fully trusted. For untrusted configs, a more constrained parser would be safer. **Recommended scenarios** - Use this skill when you need to generate **bash** scripts that must be reasonably robust, maintainable, and self-documenting, especially for automation and DevOps workflows on Linux or macOS. - It is particularly appropriate when the user explicitly asks for: - Argument parsing with flags/options and `--help` output. - Reliable cleanup (temp files/directories) and error handling in multi-step scripts. - Parallel or background task execution with progress and failure tracking. - Safer wrappers around destructive commands (with confirmation, lock files, or retries). **Caution:** When the user requires strict POSIX `/bin/sh` compatibility or highly portable scripts across very diverse environments, this skill should be applied carefully, adapting away from bashisms (arrays, `[[ ]]`, `BASH_SOURCE`, `grep -P`, GNU-only options) and reconsidering reliance on `set -e` in complex control structures.