What are the caveats of having one single file with environment variables?

What I would like to do is to create a file (e.g. ~/.env) which contains all necessary PATH declarations and possibly other non-confidential environment variables, such as EDITOR and GOPATH, and have this file sourced from within each of shell-specific dotfiles.

Specifically, I would want to include the line

    . "$HOME/.env"

to all .profile, .bash_profile, .bashrc, .zprofile, .zshenv, .zshrc

The goal is to have a consistent behaviour of commands executed in interactive/non-interactive and login/non-login shells.

Why would I not want to do this? Are there any problems that may occur because of this?

I have read a bunch of answers on SE related to the topic such as


and I understand what are some suggested practices of env declarations. However, I would like to know if the method above is also acceptable and safe.

  • Also: superuser.com/a/183980/513541 – Jeff Schaller Jul 17 '18 at 23:34
  • consider what you've already read in the SU post: The reason is that zsh has enough incompatibilities with standard shells to break scripts., so any syntax you use has to be compatible with the shells you expect to source that file with. – Jeff Schaller Jul 17 '18 at 23:35
  • 2
    it sounds like you're describing /etc/environment – jeremysprofile Jul 18 '18 at 0:19
  • @JeffSchaller Yes, thank you. I do keep the syntax compatible. – mikeonly Jul 18 '18 at 1:53
  • @jeremysprofile Partially so. I could use /etc/environment in the same way and source it from everywhere, but on macOS I believe /etc is protected, and I would like to keep the file locally. The purpose would be the same though, so yes. – mikeonly Jul 18 '18 at 1:57

The only issue with this is that if you source the file from both .bash_profile and .bashrc, and if those two files source each other (and similarly for other shells), then you may source your environment file multiple (two) times when starting a shell session.

This is not an issue unless you append/prepend values to environment variables.

You could protect against this by setting a shell variable like env_sourced to some value in file and then testing it at the top:

# My environment file

[ -n "$env_sourced" ] && return

# etc.
  • #ifndef _MYHEADER_H ... – Bananguin Jul 18 '18 at 7:25
  • @Bananguin Yes, it's an include guard, like what you would find in C headers. – Kusalananda Jul 18 '18 at 7:27

I don't see why you should not do this. For instance, I'm working in a mixed bash/zsh environment (i.e. I use in some terminal windows bash, and in some zsh). I put those definitions - environment variables, non-exported variables, shell functions -, which are syntactically compatible for both languages, in one common file, which I'm sourcing from .bashrc and from .zshrc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.