Choosing a Default Shell for Minimal Unix Containers: ash, dash, bash, or zsh

Decision and constraints

When building a minimal container image you must decide which Unix shell to provide as the default interactive interpreter (often linked at /bin/sh). The decision hinges on four constraints: image size, POSIX compliance for portable scripts, interactive usability for debugging, and startup latency. Larger shells add features but increase attack surface and build time.

Comparison of supported shells

Shell	Approx. size	POSIX compliance	Interactive features	Typical startup time
ash (Almquist Shell)	~200 KB	Full	Basic prompt, no line editing or history	Very low
dash	~150 KB	Full	Minimal prompt, no advanced editing	Lowest
bash	~1 MB	Mostly (includes bash‑specific extensions)	History, completion, arrays, associative arrays	Moderate
zsh	~1.5 MB	Mostly (compatible with bash scripts)	Advanced completion, spelling correction, plugin framework	Highest

Trade‑off explanation

If your container only runs non‑interactive workloads (e.g., a single executable service), dash or ash give the smallest footprint and fastest script execution while remaining strictly POSIX‑compliant. This reduces the attack surface and satisfies size‑optimization policies.

When you need an interactive shell for debugging or occasional manual tasks, bash provides a comfortable experience with history and tab completion at a modest size increase. zsh offers the richest interactive environment but adds significant size and startup overhead, making it suitable only when usability outweighs strict minimalism.

Portability tip: scripts that rely on bash‑specific arrays (arr=(a b)) or arithmetic ($((i+1))) will fail if /bin/sh points to dash or ash. Use set -euo pipefail and stick to POSIX constructs to avoid surprises.

Concrete implementation and validation

The following Dockerfile snippet shows how to set dash as the default shell and verify the choice.

# Use a minimal base (e.g., alpine)
FROM alpine:3.20

# Install dash (already present in alpine as /bin/sh, but we make it explicit)
RUN apk add --no-cache dash

# Ensure /bin/sh points to dash
RUN ln -sf /bin/dash /bin/sh

# Set environment variable for interactive shells (optional)
ENV SHELL=/bin/dash

# Verify shell identity and size
RUN sh -c 'echo "Shell: $SHELL"' \
    && ls -l $(which sh) \
    && sh --version

# Run a POSIX‑only test script
COPY test.sh /usr/local/bin/test.sh
RUN chmod +x /usr/local/bin/test.sh \
    && /usr/local/bin/test.sh

The accompanying test.sh contains only POSIX features:

#!/bin/sh
printf "2+2=%s\n" $((2+2))
if [ "$(uname -s)" = "Linux" ]; then
    echo "Running on Linux"
fi

To check the result after building the image, run a container and inspect the shell:

docker build -t shell-test .
docker run --rm shell-test sh -c 'echo $SHELL; which sh; ls -l $(which sh)'

Expected output shows /bin/dash as the symlink, a small file size (~150 KB), and the arithmetic test printing 2+2=4. If you replace dash with bash or zsh in the RUN apk add and symlink steps, you can observe the size increase and the presence of interactive features (e.g., bash --version reports version 5.x).

Limitations and practical verification

Size numbers are approximate and depend on the base distribution and linking choices. Always verify the actual binary size in your image with ls -l $(which sh). Interactive features such as history are only available when the shell is invoked interactively; non‑interactive script execution will behave the same across all four shells for POSIX‑only code.

To confirm that your chosen shell provides the desired usability, you can run an interactive container and test a feature:

docker run -it --rm shell-test sh
# Inside the shell:
echo test   # press Enter
history | tail -1  # shows the command if history is supported
# Press Tab after typing part of a command to see completion (bash/zsh only)

If the history command returns nothing or completion does not trigger, the shell lacks those interactive capabilities.