Bash Master

Bash Scripting Mastery

Scope and platform contract

This skill targets Bash itself, wherever Bash runs - Linux, macOS, WSL, Git Bash / MSYS2 on Windows, and Bash-based container images. It does not cover native PowerShell: a PowerShell script is a different language and should use powershell-master. On Windows, bash-master assumes the user is running Bash inside Git Bash, WSL, or a similar Bash environment, and addresses the MSYS path-translation quirks that result.

Repository conventions

Project-level conventions (Windows backslashes in tool calls, documentation discipline, etc.) live in the agent body and the windows-path-master plugin. This skill focuses on Bash content; do not duplicate that boilerplate here.

Quick reference

#!/usr/bin/env bashset -euo pipefail  # Exit on error, undefined vars, pipe failuresIFS=$'\n\t'        # Safe word splitting# Run shellcheck your_script.sh before deployment.# Test on every target platform before production.

Bash-portability quick check:

# Linux/macOS:       Full bash features# Git Bash (Windows): Most features, some system calls missing (no systemd, /proc differs)# WSL:               Effectively Linux; /mnt/c for Windows filesystem# Containers:        Depends on base image - alpine ships /bin/sh, not bash# POSIX mode:        Use /bin/sh and avoid bashisms

When to use this skill

Always activate for:

• Writing or modifying any bash/shell script
• Reviewing or refactoring existing scripts
• Debugging shell script failures
• DevOps automation, CI/CD pipelines, system administration
• Cross-environment Bash portability (Linux <-> macOS <-> WSL <-> Git Bash <-> container)

Do not use this skill for:

• PowerShell scripts - use powershell-master
• Batch (.cmd/.bat) scripting
• Generic command help unrelated to scripting

Core principles

1. Safety first

Every script should open with the safety preamble:

#!/usr/bin/env bashset -e            # Exit on any errorset -u            # Exit on undefined variableset -o pipefail   # Catch failures mid-pipelineset -E            # Inherit ERR trap into functionsIFS=$'\n\t'       # Avoid word splitting on spaces
readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"readonly SCRIPT_NAME="$(basename "${BASH_SOURCE[0]}")"

2. POSIX vs Bash

3. Quoting

# Always quote expansionsprocess "$file_path"        # correctprocess $file_path          # word-splitting bug
# Arraysfiles=("file 1.txt" "file 2.txt")process "${files[@]}"       # each element kept separateprocess "${files[*]}"       # joined as one string - usually wrong

4. ShellCheck

Run shellcheck on every script. Only disable warnings with a justification comment: # shellcheck disable=SC2086 reason: intentional word splitting.

See references/best_practices.md for the full quoting/style table and references/patterns_antipatterns.md for the common pitfalls.

Platform-specific considerations

Git Bash / MSYS2 (Windows)

Git Bash auto-converts Unix-style arguments to Windows paths. This is the largest single source of cross-platform Bash bugs on Windows.

# The conversion: /foo becomes C:/Program Files/Git/usr/foo# Disable per-command:MSYS_NO_PATHCONV=1 command /path/that/should/stay/unix
# Manual conversionunix_path=$(cygpath -u "C:\Windows\System32")win_path=$(cygpath -w "/c/Users/username")
# Detect Git Bashif [[ "$OSTYPE" == "msys" ]] || [[ "$OSTYPE" == "mingw"* ]]; then    : # Git Bashficase "${MSYSTEM:-}" in    MINGW64|MINGW32|MSYS) : ;;  # MSYS2 / Git Bash environmentesac
# Flags that look like pathscommand //e //s   # double-slash to suppress conversioncommand -e -s     # or use dash-options

Full Git Bash + Windows path notes live in references/windows-git-bash-paths.md.

Linux

GNU coreutils, /proc, systemd integration. Detect via [[ "$OSTYPE" == "linux-gnu"* ]].

macOS

BSD utilities behave differently from GNU. Most common gotchas: sed -i '' (empty string required), date flags differ, readlink -f not available on stock macOS.

if command -v gsed >/dev/null; then SED=gsed; else SED=sed; fi

WSL

Effectively Linux. The Windows filesystem is mounted at /mnt/c/. Detect via grep -qi microsoft /proc/version.

Containers

Alpine images ship only /bin/sh (BusyBox). Write POSIX-compliant scripts or apk add bash. Container init quirks: PID 1 must reap children and handle signals. Detect via [ -f /.dockerenv ] or [ -n "$KUBERNETES_SERVICE_HOST" ].

Portable platform-detection template

detect_platform() {    case "$OSTYPE" in        linux-gnu*)    echo "linux" ;;        darwin*)       echo "macos" ;;        msys*|cygwin*) echo "windows" ;;        *)             echo "unknown" ;;    esac}

Full per-platform tables (BSD-vs-GNU coreutils flags, WSL networking, container init patterns) live in references/platform_specifics.md.

Best practices (summary)

The full patterns - function design, error handling, input validation, argument parsing, logging - live in references/in-depth-patterns.md. The headline rules:

• One concern per function; locals declared first; validate input; return non-zero on error.
• Constants UPPER_CASE; locals lower_case; mark immutable values readonly.
• Always check exit codes (if ! cmd, ||, traps, or a central error_exit helper).
• Validate every external input - empty, format, length, charset.
• Use getopts or a case-based argument parser; print usage and exit 1 on bad input.
• Use a leveled logger that writes to stderr.

Security, performance, testing, debugging, advanced patterns

These each have dedicated sections in references/in-depth-patterns.md:

Read that reference any time you need the canonical code template for one of those topics.

Reference files

• references/platform_specifics.md [blocked] - Detailed platform differences and workarounds
• references/best_practices.md [blocked] - Comprehensive industry standards and guidelines
• references/patterns_antipatterns.md [blocked] - Common patterns and pitfalls with solutions
• references/windows-git-bash-paths.md [blocked] - Git Bash / MSYS path-translation reference
• references/in-depth-patterns.md [blocked] - Function design, security, performance, testing, debugging, advanced patterns
• references/resources.md [blocked] - Official docs, style guides, tooling, and learning links

Success criteria

A Bash script written with this skill should:

1. Pass shellcheck with no warnings
2. Begin with set -euo pipefail
3. Quote every variable expansion
4. Print usage on -h/--help
5. Decompose into testable functions
6. Handle empty input, missing files, and unexpected arguments
7. Run on every target platform (Linux/macOS/WSL/Git Bash/container) where it claims support
8. Match the Google Shell Style Guide
9. Clean up on exit (trap EXIT)
10. Be unit-tested with BATS where logic is non-trivial

# Pre-deployment checklistshellcheck script.shbash -n script.shbats test/script.bats./script.sh --helpDEBUG=true ./script.sh

Troubleshooting

Script fails on a different platform

• checkbashisms script.sh to surface non-portable constructs.
• command -v tool to verify a required tool is installed.
• Diff command flags between GNU and BSD (sed --version etc.).

ShellCheck warnings

• Read the rule explanation (shellcheck -W SC2086).
• Fix the underlying issue; only disable a rule with a justification comment.

Works interactively but fails in cron

• Cron has a minimal PATH - set PATH explicitly.
• Use absolute paths.
• Redirect stdout/stderr: ./script.sh >> /tmp/cron.log 2>&1.

Performance issues

• Profile with time.
• Enable set -x to find slow steps.
• Replace external invocations with Bash built-ins where possible.