Show HN: Dotenv, if it is a Unix utility

Original Article ↗ Hacker News Discussion ↗

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.