Before shipping a script that begins with `#!/bin/sh` to hosts where /bin/sh is dash, how would you check it for bash-only constructs, and what does `dash -n script.sh` fail to catch?

## Why eyeballing it does not work Bashisms are invisible to people who write bash all day, because they read as ordinary shell. `[[ -n $x ]]`, `source lib.sh`, `local n=1`, `echo -e`, `${file%.*}` versus `${file/.txt/}`, `read -a`, `$'\n'`, `<(cmd)`, `&>log` — some of those are POSIX and some are not, and the boundary is not intuitive. The only reliable checks are mechanical. ## Layer 1: parse it with the target shell ```sh dash -n deploy.sh busybox sh -n deploy.sh ``` `-n` is the POSIX "read commands but do not execute them" option. It uses the real parser, so it is authoritative about grammar, and it is safe to run on a script that would otherwise delete things. What it catches is anything that is a **syntax** error in POSIX: ```sh arr=(a b c) # caught: parenthesis in an assignment function deploy { } # caught: the function keyword diff <(a) <(b) # caught: process substitution ``` What it misses is everything that is *syntactically valid but semantically absent*. `[[ -n "$x" ]]` parses fine — `[[` is simply a command word to dash, and the failure only appears at runtime as `[[: not found`. The same goes for `local`, `source`, `echo -e`, `${var/old/new}` (a bad-substitution error at expansion time) and every bash-only option to a builtin. A clean `-n` run therefore proves very little. ## Layer 2: checkbashisms `checkbashisms` ships in Debian's **devscripts** package and exists because Debian had to audit thousands of maintainer scripts when it moved `/bin/sh` to dash. It is a text scanner that knows a long list of bash-only constructs and reports them with line numbers. Because it is textual, it flags things inside comments or strings occasionally, and it cannot see a bashism that arrives through a variable or an `eval`. Treat its output as a to-do list, not a verdict — but it is fast, it needs no execution, and it catches the runtime-only cases that `-n` cannot. ## Layer 3: shellcheck, in CI `shellcheck` is the one to standardise on. It parses the script properly, infers the dialect from the shebang, and can be forced with `--shell=sh` or an in-file `# shellcheck shell=sh` directive. Non-POSIX constructs come out as warnings of the form "In POSIX sh, `[[ ]]` is undefined" — a whole numbered family reserved for portability, separate from its ordinary correctness warnings. Because it understands scope and quoting it produces far fewer false alarms than a grep, and it fails a build with a non-zero exit status, which is what actually keeps a repository honest over time. ## Layer 4: run it Static analysis cannot tell you that the script calls `readlink -f` (not portable to macOS), `sed -i` without an argument (BSD sed wants one), or `grep -P`. Those are not shell dialect at all — they are the *utilities*, and the same portability question applies to them. So run the script's tests under the real interpreter on the real base image: ```sh docker run --rm -v "$PWD:/w" -w /w debian:stable dash ./run-tests.sh docker run --rm -v "$PWD:/w" -w /w alpine:3 sh ./run-tests.sh ``` ## The check that is not a check `bash --posix script.sh` and `set -o posix` look like portability tests and are not. POSIX mode makes bash *conform* on a list of specific behaviours; it does not remove `[[ ]]`, arrays, `local`, `source` or brace expansion from the language. A script full of bashisms passes `bash --posix` cleanly and then dies under dash. Likewise, running `sh script.sh` on a RHEL box is running bash. ## What good practice looks like Put `shellcheck` in CI over every script in the repository, let the shebang declare the dialect, and run at least one smoke test on the minimal image the script will actually meet in production. That combination costs seconds per build and removes an entire class of "works on my machine" incidents.