user environment variables strategy

xand · 2019-12-20 13:48:15

Hello guys,
the "user level" environment vars on my system are basically defined on two places:

* shell config file (i.e. config.fish): this is where the bulk of it resides, especially XDG-related stuff.

* ~/.config/environment.d/envvars.conf: specific to sway and systemd user units

I started to have a feeling that `envvars.conf` was a better place for these variables, so what is your take on moving all I can to `envvars.conf`? I know it's not common practice, but is it silly?

I know things like commands such as `set -gx SSH_AUTH_SOCK (gpgconf --list-dirs agent-ssh-socket)` is not supported. Also, I have to find a way (please help ) to import these vars back to shell.

Have a nice day

Trilby · 2019-12-20 15:15:48

Environment variables are not global variables. Don't try to treat them as such.

Set environment variables in the environment where you want to use them. It's as simple as that.

~/.config/environment.d/ is the proper place to set variables you want to be available to systemd user services for your user only. /etc/systemd/user.conf is the propler place for those you want available to all user services. There are other places for variables you want available to all systemd services. And if you want a variable available to just a single service, it goes in the service file.

Then of course if you want a variable available to the interactive shell session, you put it in the rc/conf file for your interactive shell or your shell profile.

xand wrote:

I started to have a feeling that `envvars.conf` was a better place for these variables

Only for the ones that are mean't to be there.

xand wrote:

I know things like commands such as `set -gx SSH_AUTH_SOCK (gpgconf --list-dirs agent-ssh-socket)` is not supported. Also, I have to find a way (please help ) to import these vars back to shell.

I'm not sure what you mean by "not supported", but yes, anything needed in an interactive shell is of no use in the system.d user environment. You could source ~/.config/environment.d/*.conf from your shellrc file if you really wanted - it'd be harmless and acheive your goals - but that seems pretty ugly to me.

xand · 2019-12-20 15:36:11

Thanks for replying Trilby, your writing is very reasonable to me.

Besides the nice explanation, I understand you do think it is silly (and also ugly ) moving vars from shell config to environment.d and importing them back.

I don't feel like doing such move anymore, and maybe my user environment vars placement are already on the correct path.

I have a question though, I must have $GNUPGHOME set for both, shell and systemd so by now I have it set on `config.fish` and `envvars.conf`. Is this OK or a redundancy?

Trilby · 2019-12-20 18:23:40

Good point. You could use `systemctl --user import-environment` optionally with that variable name in your profile, e.g.

#shell variables
MANPAGER=whatever
EDITOR=vim

#shell and systemd user session variables
GNUPGHOME=whatever
ANOTHERSHARED=thing

systemctl --user import-environment GNUPGHOME ANOTHERSHARED

eschwartz · 2019-12-20 18:50:17

You could use ~/.pam_environment to define environment variables that need to exist for all sessions (including the systemd --user environment).

e.g. PATH, or XDG_*

xand · 2019-12-21 14:26:18

@eschwartz, that would definitely be my first go if I were not so committed to keep all config files under XDG specification. Thanks for pointing that out.

@Trillby, you nailed it, thanks again pal.

eschwartz · 2019-12-22 00:17:52

xand wrote:

@eschwartz, that would definitely be my first go if I were not so committed to keep all config files under XDG specification. Thanks for pointing that out.

That does of course leave open the question of what you first use to set up XDG, since whatever that is cannot be something that requires XDG in order to find it.

Trilby · 2019-12-22 02:12:17

Well that's easy:

export XDG_OUROBOROS=$XDG_OUROBOROS

xand · 2019-12-22 13:27:47

eschwartz wrote:

xand wrote:
@eschwartz, that would definitely be my first go if I were not so committed to keep all config files under XDG specification. Thanks for pointing that out.
That does of course leave open the question of what you first use to set up XDG, since whatever that is cannot be something that requires XDG in order to find it.

haha, yeah XDG seem like a "chicken/egg" problem so I chose "fish" to deal with it.

Arch Linux

#1 2019-12-20 13:48:15

user environment variables strategy

#2 2019-12-20 15:15:48

Re: user environment variables strategy

#3 2019-12-20 15:36:11

Re: user environment variables strategy

#4 2019-12-20 18:23:40

Re: user environment variables strategy

#5 2019-12-20 18:50:17

Re: user environment variables strategy

#6 2019-12-21 14:26:18

Re: user environment variables strategy

#7 2019-12-22 00:17:52

Re: user environment variables strategy

#8 2019-12-22 02:12:17

Re: user environment variables strategy

#9 2019-12-22 13:27:47

Re: user environment variables strategy

Board footer