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, 2018 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, 2018 at 23:35
  • 2
    it sounds like you're describing /etc/environment Jul 18, 2018 at 0:19
  • @JeffSchaller Yes, thank you. I do keep the syntax compatible.
    – mikeonly
    Jul 18, 2018 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, 2018 at 1:57

2 Answers 2


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, 2018 at 7:25
  • @Bananguin Yes, it's an include guard, like what you would find in C headers.
    – Kusalananda
    Jul 18, 2018 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .