Earlier quoted context omitted.
I've got a hand rolled direnv that's quite simple: function lenv { path=$PWD while [[ ! -f "$path/.env" && "$path" != '/' ]]; do path=$(dirname "$path") done if [ -f "$path/.env" ]; then source "$path/.env" fi } function cd { builtin cd "${@}"; lenv; } It lacks the security but it works recursively and allows more than just environment variables. A common script I have is to automatically build for instance: here=$(d…
direnv does allow more than just environment variables, you can run arbitrary commands. Personally I wouldn't run potentially expensive commands like building the project, but if that's really what's best for your workflow, it can be done. If there is no .envrc in the directory it will look for one in the parent directory, but it won't activate more than one. Also one thing it does that your hand-rolled version does…
My above example wasn't running the command, just defining it to be run manually. The .env becomes a dumping ground for all sorts of project specific stuff. The docs say direnv doesn't support this.
> Also one thing it does that your hand-rolled version does not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.
I've thought of adding this, but apart from a couple of things I reset manually I haven't really found the need.