Posix Shell Pro

Use this skill when

- Working on posix shell pro tasks or workflows

- Needing guidance, best practices, or checklists for posix shell pro

Do not use this skill when

- The task is unrelated to posix shell pro

- You need a different domain or tool outside this scope

Instructions

- Clarify goals, constraints, and required inputs.

- Apply relevant best practices and validate outcomes.

- Provide actionable steps and verification.

- If detailed examples are required, open `resources/implementation-playbook.md`.

Focus Areas

- Strict POSIX compliance for maximum portability

- Shell-agnostic scripting that works on any Unix-like system

- Defensive programming with portable error handling

- Safe argument parsing without bash-specific features

- Portable file operations and resource management

- Cross-platform compatibility (Linux, BSD, Solaris, AIX, macOS)

- Testing with dash, ash, and POSIX mode validation

- Static analysis with ShellCheck in POSIX mode

- Minimalist approach using only POSIX-specified features

- Compatibility with legacy systems and embedded environments

POSIX Constraints

- No arrays (use positional parameters or delimited strings)

- No `[[` conditionals (use `[` test command only)

- No process substitution `<()` or `>()`

- No brace expansion `{1..10}`

- No `local` keyword (use function-scoped variables carefully)

- No `declare`, `typeset`, or `readonly` for variable attributes

- No `+=` operator for string concatenation

- No `${var//pattern/replacement}` substitution

- No associative arrays or hash tables

- No `source` command (use `.` for sourcing files)

Approach

- Always use `#!/bin/sh` shebang for POSIX shell

- Use `set -eu` for error handling (no `pipefail` in POSIX)

- Quote all variable expansions: `"$var"` never `$var`

- Use `[ ]` for all conditional tests, never `[[`

- Implement argument parsing with `while` and `case` (no `getopts` for long options)

- Create temporary files safely with `mktemp` and cleanup traps

- Use `printf` instead of `echo` for all output (echo behavior varies)

- Use `. script.sh` instead of `source script.sh` for sourcing

- Implement error handling with explicit `|| exit 1` checks

- Design scripts to be idempotent and support dry-run modes

- Use `IFS` manipulation carefully and restore original value

- Validate inputs with `[ -n "$var" ]` and `[ -z "$var" ]` tests

- End option parsing with `--` and use `rm -rf -- "$dir"` for safety

- Use command substitution `$()` instead of backticks for readability

- Implement structured logging with timestamps using `date`

- Test scripts with dash/ash to verify POSIX compliance

Compatibility & Portability

- Use `#!/bin/sh` to invoke the system's POSIX shell

- Test on multiple shells: dash (Debian/Ubuntu default), ash (Alpine/BusyBox), bash --posix

- Avoid GNU-specific options; use POSIX-specified flags only

- Handle platform differences: `uname -s` for OS detection

- Use `command -v` instead of `which` (more portable)

- Check for command availability: `command -v cmd >/dev/null 2>&1 || exit 1`

- Provide portable implementations for missing utilities

- Use `[ -e "$file" ]` for existence checks (works on all systems)

- Avoid `/dev/stdin`, `/dev/stdout` (not universally available)

- Use explicit redirection instead of `&>` (bash-specific)

Readability & Maintainability

- Use descriptive variable names in UPPER_CASE for exports, lower_case for locals

- Add section headers with comment blocks for organization

- Keep functions under 50 lines; extract complex logic

- Use consistent indentation (spaces only, typically 2 or 4)

- Document function purpose and parameters in comments

- Use meaningful names: `validate_input` not `check`

- Add comments for non-obvious POSIX workarounds

- Group related functions with descriptive headers

- Extract repeated code into functions

- Use blank lines to separate logical sections

Safety & Security Patterns

- Quote all variable expansions to prevent word splitting

- Validate file perm