Shell Scripting
Master shell scripting best practices, error handling, portability, debugging, and performance optimization for reliable automation scripts
npx skills add cosmicstack-labs/mercury-agent-skills --skill shell-scripting --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Explains how to write shell scripts with explicit failure on errors, clarity, portability to POSIX sh, defensive safety for empty variables and missing files, and predictable behavior with clear exit codes. It targets maturities up to and beyond defensive levels, and requires using functions, help text, argument parsing, cleanup traps, and structured error handling. It prescribes a comprehensive script structure, including shebang, set -euo pipefail, logging helpers, and modular functions for validation, building, and deployment. It also covers portability differences between Bash and POSIX sh, recommended quoting habits, and robust error and exit code conventions.
How it works
- It instructs start with a shebang and set of safety flags (set -euo pipefail).
- Organize logic into reusable, named functions with a naming convention (validate_, build_, deploy_, cleanup_).
- Implement a main() function with argument parsing and a guarded entry point so the script can be sourced for testing.
- Provide example implementations for logging (log_info, log_warn, log_error) and core operations (validate_environment, build_application, deploy_application).
- Emphasize exit codes and a standardized mapping for common conditions, including 0 for success and 1 for general error, with additional codes for specific situations.
- Establish an Error Handling framework: fatal, warn, assert, and trap-based cleanup to guarantee resource cleanup on exit.
- Include a thorough Portability section detailing Bash vs POSIX sh considerations, OS differences, and ensuring portability with POSIX behavior when possible.
- Describe best practices for quoting, using [[ ]] over [ ], safe temporary file handling with mktemp, and robust argument parsing via getopts or manual parsing.
- Provide concrete code blocks demonstrating patterns for logging, error handling, cleanup, and argument parsing.
When to use it
- Use when building automation scripts that must be reliable across environments and shells.
- Apply to scripts intended to run unattended, where predictable exit behavior and robust error handling are required.
- Follow when aiming for mature scripting levels (Defensive, Robust, Production) per the Script Structure and Scripting Maturity Model sections.
What it can touch
- The skill recommends using functions, environment setup, and argument parsing logic within shell scripts. It discusses using POSIX-compatible constructs and Bash-specific features only when documented as acceptable for portability.
Caveats
- The material emphasizes defensive coding and explicit exit behavior but also notes edge cases (e.g., set -e limitations inside conditionals).
- It requires adherence to prescribed exit codes and structured cleanup via traps, which may require careful implementation to avoid unintended exits in complex scripts.
# Shell Scripting ## Core Principles ### 1. Fail Explicitly A script that encounters an error should stop, not continue with corrupted state. Use defensive coding: validate assumptions, check exit codes, and never assume success. ### 2. Clarity Over Cleverness Shell scripting is already cryptic enough. Write scripts that are easy to read, not impressive one-liners. Your future self will thank you. ### 3. Portability By Default Unless you have a specific reason to require Bash 4+, write for POSIX sh. Your script may need to run in a container, an embedded system, or a legacy environment. ### 4. Defensive Safety Every variable could be empty. Every command could fail. Every file could be missing. Write scripts that survive these realities. ### 5. Principle of Least Surprise Scripts should behave predictably. Use consistent exit codes, clear error messages, and help text. No silent failures, no hidden side effects. ## Scripting Maturity Model | Level | Name | Description | |-------|------|-------------| | 0 | Ad-hoc | One-off commands saved to a file. No error handling. Only the author understands it. | | 1 | Functional | Has shebang and basic structure. Handles common success paths.
- Core Principles
- 1. Fail Explicitly
- 2. Clarity Over Cleverness
- 3. Portability By Default
- 4. Defensive Safety
- 5. Principle of Least Surprise
- Scripting Maturity Model
- Script Structure
- Shebang and Set Flags
- Functions
- main() Guard
- Exit Codes
- Error Handling
- set -euo pipefail (The Holy Trinity)
set -euo pipefail
local env="${1:-}"
case "$env" in
esac
log_info "Starting build..."
npm run build || return 1
log_info "Build completed successfully"
local env="$1"
log_info "Deploying to $env..."
local env="staging"What does the Shell Scripting skill do?
Master shell scripting best practices, error handling, portability, debugging, and performance optimization for reliable automation scripts
How do I install it?
Run `npx skills add cosmicstack-labs/mercury-agent-skills --skill shell-scripting --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From cosmicstack-labs/mercury-agent-skills, a repository with 364 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.