Show HN: #!/usr/bin/env docker run

Original Article ↗ Hacker News Discussion ↗

A clever hack turns a Dockerfile into an executable script via a shebang that invokes `docker build` and `docker run`, effectively bundling code, dependencies, and runtime into a single file. Commenters are split between admiring the elegance of a self-contained, executable Dockerfile and criticizing it as unreadable, non-portable, and unnecessary compared to simpler Bash scripts, Nix/Guix shebangs, or conventional container tooling. The exchange broadens into a debate over container ecosystems (Docker vs. Podman, Windows and macOS support), the value of single-file artifacts, and how best to package and isolate complex application stacks.

What the hack does

  • Turns a Dockerfile into an executable script via a shebang that calls env → bash → docker build and docker run.
  • Running ./Dockerfile both builds and runs the container, instead of separate docker build and docker run steps.
  • Some see it as a clever “Docker shebang” or “self-building, self-executing Dockerfile”; others stress it’s mostly a neat trick, not something to standardize in repos.

Single-file vs multi-file and heredocs

  • Many dislike large heredoc sections inside Dockerfiles or shell scripts, calling them hard to read and maintain.
  • Others like single-file “full programs” for easy distribution (email, gists, quick sharing) and avoiding external script dependency drift.
  • Alternatives mentioned: bash scripts that generate files via heredocs, self-extracting archives (e.g., tarball+shell), and markdown with fenced code blocks.
  • Some argue directories are a cleaner unit of packaging; single-file obsession is seen as aesthetic more than practical.

Usefulness and use cases

  • Potential uses: shipping a whole stack or tool to customers as one file, ensuring consistent environments; quick demo apps; dependency-heavy “meta-seeds.”
  • Others say complexity and surprise factor (“WTF level”) make it inappropriate for team or production code, where a plain bash wrapper is clearer.

Shebang mechanics and portability

  • Relies on /usr/bin/env -S (split-string) to pass multiple arguments in a shebang; this is GNU coreutils-specific and relatively recent.
  • Shebang behavior with spaces and multiple arguments is non-standard; POSIX leaves results “unspecified.”
  • Shebang length limits (~256 bytes) and OS differences are flagged as additional portability hazards.

Containers, Docker, and alternatives

  • Debate over calling this “cross-platform”: Docker needs a Linux kernel (VM on macOS/most Windows), though native Windows containers exist.
  • Discussion of Windows containers, WSL, Hyper-V; some say Windows container support is real but poorly marketed.
  • Podman, CRI-O, runc/crun, bubblewrap, Guix/Nix shell shebangs, Apptainer/Singularity, and other runtimes are cited as cleaner or more intentional approaches.
  • Broader container vs “just run it on the host” debate: containers help isolate complex dependency sets; others find them overkill for personal projects.