5

It seems to me like with environment.d now sourcing environmental variables in ~/.config/environment.d/*.conf that we should no longer have environmental variables declared in ~/.bashrc or ~/.profile or the like. If for no other reason than because these declarations can be written in a shell-specific syntax.

Is this assumption correct? Is there any reason on a machine with environment.d to put our environmental variables (that aren't shell-specific) in our shell's rc file or in ~/.profile?

2
  • 1
    Clearly the syntax is limited. If I wanted to loop over, say /opt/*/bin and add those to $PATH, I don't see how environment.d can manage that.
    – muru
    May 26, 2020 at 4:53
  • 1
    Clearly. Do I have to update the question and narrow the scope to environmental variables that are set to literals without the aid of scripting? May 26, 2020 at 4:55

1 Answer 1

4

The files serve different purposes, which remain complementary:

  • environment.d defines variables for systemd user services;
  • .bashrc, if it defines variables, defines them for any interactive, non-login instance of Bash;
  • .profile, if it defines variables, defines them for any interactive, login instance of Bash (and other shells).

Thus setting variables in .bashrc and/or .profile is guaranteed to set them in any corresponding shell instance. Setting variables in environment.d files is guaranteed to set them in any corresponding user service instance, which might include shells, but might not (and there might be other intervening layers, see sshd).

Another difference I see is that changing .bashrc or .profile will produce effects in any shell started thereafter; changing environment.d will only take effect when the user session and the relevant services are reloaded or restarted.

As muru mentioned in the comments, environment.d files are more limited in their capabilities than the shell initialisation scripts.

1

You must log in to answer this question.

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