From `shell` to `python` - what stops you?

uvsmtid — Sat, 21 Feb 2026 06:21:57 +0000

shell scripts are a poor choice for evolving software:

❌ (unit) test code for shell scripts is near zero
❌ no default error detection (forget set -e and an undetected disaster bubbles through the call stack)
❌ cryptic "write-only" syntax (e.g. echo "${file_path##*/}" vs os.path.basename(file_path))
❌ subtle, error-prone pitfalls (e.g. shopt nuances)
❌ unpredictable local/user overrides (e.g. PATH points to unexpected binaries)
❌ less cross-platform than it seems even on *nixes (e.g. divergent command behaviors: macOS vs Linux)
❌ no stack traces on failure (which encourages noisy, excessive logging instead)
❌ limited native data structures (no nested ones)
❌ no modularity (code larger than one-page-one-file is cumbersome)
❌ no external libraries/packages (no enforce-able dependencies)
❌ when shell scripts multiply, they inter-depend for reuse (by source-ing) into an entangled mess
❌ being so unpredictable makes shell scripts high security risks
❌ slow
...

Do not get me wrong:

Why not `python`?

The main reason I used to resort to shell:

The need for the extra “body movements” to provide required python, populate the venv and activate it.
Automating this for any environment immediately adds wrappers which are likely shell scripts anyway.

an argless reusable one-liner to bootstrap the environment with (almost) zero pre-requisites that runs everywhere:

./prime