Show HN: Dotenv, if it is a Unix utility

Original Article ↗ Hacker News Discussion ↗

Unix-style tools for loading `.env` files are being compared to shell-based approaches like `direnv`, with a central tension between automatic, directory-scoped environments and explicit, per-command control. Commenters explore how these tools fit into workflows involving Docker, Kubernetes, and init systems, and debate whether configuration should live primarily in environment variables, files under version control, or encrypted stores. Several note that many of the same goals can be achieved with standard shell features (`env`, `set -a`, sourcing scripts), but that dedicated utilities can provide safer parsing, clearer semantics, and better ergonomics.

Comparison with direnv and shell-integrated tools

  • Some see direnv as already solving this problem: auto-loads env per-directory and shows messages when activating/deactivating.
  • Others argue dotenv is more explicit and “quiet”: you only get env vars when you consciously run dotenv cmd, no persistent or auto-loaded state.
  • Debate on whether direnv’s behavior is “implicit”: critics worry about forgetting that a directory’s env is active after many commands or long-lived shells.
  • Supporters counter that staying in a directory usually implies wanting its env, and tools like tmux can isolate workspaces.

Use cases: interactive shells vs programs/containers

  • Distinction made: direnv is tailored for interactive shells; dotenv is for wrapping a specific process.
  • Dotenv (or similar) is seen as handy for Docker, containers, init systems, and non-interactive jobs; direnv less so, though direnv exec can be used in some non-interactive cases.

Shell one-liners and homegrown equivalents

  • Many propose pure-shell approaches: sh -c '. .env; cmd', env $(cat .env) cmd, export $(xargs < .env), using set -a + source, subshells, etc.
  • These are praised as more “Unix-y,” but several caveats recur:
    • Break on comments or values with spaces.
    • Need export or set -a for child processes.
    • Security/robustness concerns when sourcing arbitrary files.
  • Some define shell functions for loading/unloading envs or handling multiple .env.* variants.

Configuration philosophy and .env practices

  • One viewpoint: avoid many .env files; have .env.example in version control and .env in .gitignore.
  • Strong skepticism of apps configured almost entirely via env vars; prefer convention-over-configuration with a small, finite set of overrides.
  • Tension between immutable, baked-in config vs env-based overrides that let non-developers tweak behavior without new builds.

Security, format, and standardization concerns

  • Some happily treat .env as trusted code and just source it; others dislike that this executes arbitrary shell, prefer a stricter data format.
  • Lack of a formal dotenv spec and differing behaviors across implementations are noted; edge cases (comments, quoting, newlines) are tricky.

Coreutils/env integration ideas

  • Multiple comments suggest env could grow a -f <file> option to load env files directly.
  • GNU coreutils mailing list discussions about such a feature, including supporting null-terminated formats, are referenced.