direnv is super useful if you're working in Python and have multiple projects: you can add an .envrc file that activates the right virtualenv whenever you enter a directory. It's one less thing to worry about.

I figure you can also use it in conjunction with `module load` to automatically load the right module when you enter a project's directory. Modules are used in many computing clusters to manage environments.

Also direnv will never execute an .envrc without permission, you need to run `direnv allow` whenever there is a new or newly modified .envrc.

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=$(dirname ${BASH_SOURCE[0]})
  function autobuild {
    (
      mkdir -p build
      cd $here/build
      ../configure
      while true; do
        make && make check
        inotifywait -qr -e close_write,delete $here/src $here/test $here/Makefile.am
      done
    )
  }

I've tried generalizing the latter but between different targets, different build systems, different projects structures etc, copy and pasting something like this per project is the least worst option.

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 not is that it remembers what the environment variables were before and restores them to that state when you exit the directory.

> Personally I wouldn't run potentially expensive commands like building the project

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.

Ohh, okay, I see.

You're right, you can't define aliases/functions using direnv. That's a shame, that does seem useful.

Re: bat. I agree with you, I don’t get the hype over this program either. It’s pretty easy to configure 'less’ to use syntax highlighting and ‘less’ is installed basically everywhere.

The main advantage of rg is how much faster it is than grep. It’s WAY faster.

I don’t use direnv but I have colleagues who do. I think the idea is that it can set environment variables/run arbitrary commands when you cd into a certain directory (such as activating a Python virtual env, for instance).

I also like that rg's default mode is to search all files recursively, skipping binary files and honoring .gitignore. 90% of the time this is just what I want.