posix-shell-pro

Expert in strict POSIX sh scripting for maximum portability across Unix-like systems. Specializes in shell scripts that run on any POSIX-compliant shell (dash, ash, sh, bash --posix).

Author

Install

Hot:4

Download and extract to your skills directory

Copy command and send to OpenClaw for auto-install:

Download and install this skill https://openskills.cc/api/download?slug=sickn33-skills-posix-shell-pro&locale=en&source=copy

POSIX Shell Pro - Strict POSIX sh Scripting Expert

Skill Overview


Write strict, fully compatible POSIX shell scripts that run on any Unix-like system, achieving maximum portability from Linux, BSD to macOS and Solaris.

Use Cases

1. Cross-Platform Script Development


When your shell scripts need to run on multiple operating systems—including Debian/Ubuntu (dash), Alpine/BusyBox (ash), macOS, FreeBSD, Solaris, and more—using POSIX sh ensures the script works correctly in any standard Unix environment, without worrying about bash version differences or dependencies on a specific shell.

2. Containers and Embedded Environments


In Docker Alpine images, BusyBox environments, embedded devices, or resource-constrained systems, bash may be unavailable or take up too much space. POSIX shell scripts use a minimal feature set, ensuring stable execution in these lightweight environments, making them the best choice for container startup scripts and embedded system initialization scripts.

3. Migrating from Bash to POSIX


When you need to convert existing bash scripts into a more portable POSIX sh format, you can systematically identify and replace bash-specific features (such as arrays, [[ conditionals, the local keyword, etc.), and provide portable alternatives while preserving full functionality and script safety.

Core Features

1. POSIX Compatibility Verification and Standards Guidance


Provide strict POSIX sh coding conventions that help developers avoid bash-specific features (like arrays, process substitution, brace expansion, [[ conditionals, etc.). Use tools such as ShellCheck (-s sh), shfmt (-ln posix), and checkbashisms for static analysis and formatting to ensure the scripts comply with the POSIX.1-2024 standard.

2. Portable Programming Patterns


Offer practical programming patterns for POSIX sh limitations, including: using positional parameters and delimited strings instead of arrays; using the [ ] test command instead of [[ ]; using . instead of source; using printf instead of echo; using case for pattern matching; and also providing portable implementations for safe error handling, temporary file management, and parameter parsing.

3. Multi-Shell Testing and CI Integration


Support matrix testing across multiple POSIX shell implementations such as dash, ash, bash --posix, yash, posh, and others. Provide CI/CD integration configuration (GitHub Actions, pre-commit hooks) to ensure compatibility across environments like Linux, macOS, Alpine, and BusyBox—especially suitable for containerized deployments and embedded system development.

FAQ

What is the difference between POSIX shell and bash?


Bash is the GNU Bourne Again Shell and a superset of POSIX sh, including many extensions (such as arrays, [[ conditionals, process substitution, etc.). POSIX sh is a standardized minimal feature set defined in the IEEE POSIX standard. Scripts written with POSIX sh can run in any compatible shell (dash, ash, bash --posix, etc.), while bash scripts that rely on bash-specific features are less portable.

How can I check whether my script complies with POSIX?


Use the following tools for verification:
1) shellcheck -s sh script.sh — check the script in POSIX mode;
2) shfmt -ln posix -d script.sh — format and check syntax;
3) checkbashisms script.sh — detect bash-specific constructs;
4) Test in different shells: dash script.sh, ash script.sh, bash --posix script.sh.
It’s recommended to integrate these checks into CI.

Why does my script fail to run on Alpine Linux?


Alpine Linux uses BusyBox ash by default (a lightweight POSIX shell), not bash. If your script uses bash-specific features (such as arrays arr=(), [[ ]] conditionals, the source command, ${var//pattern} substitution, etc.), it will fail. Options:
1) change the shebang to #!/bin/sh;
2) use POSIX-compatible syntax;
3) avoid bash features;
4) detect issues with shellcheck and checkbashisms.