Compare environment files in the Linux console

This is a very common source of problems using .env files: you have two or more different .env files like .env and .env.example.

You're a programmer and coding a new amazing feature. You're adding one or more new environment variables to your local .env file and everything is working fine on your computer.

Why? Because the variable(s) you've added have been added in your local .env file, on your computer only.

As you know, you have to create the variables in the .env.example file too but let's be honest, nobody thinks about it.

The one-liner and its output​

Copy this in your console, in the folder holding the two files:

(
  clear
  ENV1=.env
  ENV2=.env.example
  printf "\e[33;1m%-63s %s\e[0;1m\n" "Left side: ${ENV1}" "Right side: ${ENV2}"
  diff --suppress-common-lines -y \
    <(grep -v -E '^#|^$' ${ENV1}| sort) \
    <(grep -v -E '^#|^$' ${ENV2} | sort) \
   | grep -v 'APP_KEY'
)

On two .env files that have drifted apart, here is what comes back:

Left side: .env                   Right side: .env.example
ALLOW_FEATURE_DO_THIS = true    <
DATABASE_TYPE = pgsql           | CACHE_DRIVER = redis
                                > DATABASE_TYPE = mysql

How to read:

• ALLOW_FEATURE_DO_THIS is only present in .env,
• DATABASE_TYPE is initialized to pgsql in .env and to mysql in .env.example,
• CACHE_DRIVER is only present in .env.example and
• all other lines are strictly identical (remember we've ignored commented and empty lines)

Three lines of output, and the answer to "what did I forget to report in .env.example?" is right there.

Why plain diff isn't enough​

diff alone (see Linux - Comparing two folders/files in the console for the general case) would drown you in noise, because:

1. We don't care about comments and empty lines. If a variable has been commented, we just need to ignore it.
2. We don't care about the position in the file where the variable is declared. If APP_ENV = local is on the first line, in the middle of the file or just before the last line, we don't care about it.
3. We can also ignore some variables that we know should be different, like APP_KEY f.i.

That's exactly what the three helpers around diff are doing: grep -v -E '^#|^$' drops comments and blank lines, sort neutralizes the order, and the final grep -v 'APP_KEY' removes the variables you already know will differ.

The flag --suppress-common-lines -y does the rest: display the result in two columns (-y) and only the differences (--suppress-common-lines).

Reproduce it​

Let's try... Below we'll create the file .env.example with two lines then copy it to .env and just add a new line in .env.example. Finally, we'll sort .env.example so the order will differ with .env.

$ mkdir -p /tmp/playing_env && cd $_
$ echo 'APP_NAME = My application' > .env.example
$ echo 'APP_ENV = local' >> .env.example
$ cp .env.example .env
$ echo 'APP_KEY = 5a0678afd37f4b8d/8d9451a7381266e3' >> .env
$ echo 'APP_KEY = 3445118442a942d1/afd37466fadd5223' >> .env.example
$ echo 'CACHE_DRIVER = redis' >> .env.example
$ sort -o .env.example .env.example
▋

Now that we have our two files with one single difference, running the command above gives:

Left side: .env                   Right side: .env.example
                                > CACHE_DRIVER = redis

The column on the left represents the first file (in our example .env) while the column on the right is for the second file (.env.example). So: CACHE_DRIVER exists only in .env.example.

For the illustration, we can now add a new key but just in .env (real world situation: I'm coding a new feature and I add a variable like a switch on/off)

$ echo 'ALLOW_FEATURE_DO_THIS = true' >> .env▋

Now the output will be:

Left side: .env                   Right side: .env.example
ALLOW_FEATURE_DO_THIS = true    <
                                > CACHE_DRIVER = redis

Last sample, the same key with two different values on each side:

$ echo 'DATABASE_TYPE = pgsql' >> .env
$ echo 'DATABASE_TYPE = mysql' >> .env.example▋

And you're back to the three-line output shown at the top of this article, where the | marker appears: same key, different values.

Conclusion​

Nobody thinks about updating .env.example — that's the whole problem, and no amount of good intentions fixes it. A one-liner you can paste before every commit does, because it takes two seconds and answers with three lines or nothing at all.

Once you know which keys are missing, the next step is to add them everywhere without editing each file by hand: Batch edit of environment file. And to consume those variables from your scripts, see Bash - Loading environment variables from a file.