ZSH: Where to place environment variable so that launched application can pick it up?

Question

I need an environment variable KEY="value" made available to a GUI application before starting it. The launcher file (the one that places the icon on the desktop and sidebar in Ubuntu) has a value of Exec=/path/to/executable/file.

When using ZSH, where should I define this variable so that it is available to that application whether I click the application launcher or whether I directly type /path/to/executable/file in my shell?

In my command line prompt, I tried typing both KEY="value" and export KEY="value" before clicking the launcher, but it didn't seem to work. I also tried both of those lines in my ~/.zshrc, did a source ~/.zshrc from my shell then clicked the launcher again, but that also didn't work.

Which file should it go in? I believe have a choice of ~/.zshenv, ~/.zprofile, ~/.zshrc, and ~/.zlogin.

(For bonus points, should I use export or not?)

(Am I required to at least log out and log back in, before the variable becomes available to the application when it's launched from the launcher?)

Solution 1

As you want the variable to be defined as well in your terminal shells (interactive non-login shell) and for the desktop launcher icons (X-server started by non-interactive login shell) you should put the definition in your ~/.zshenv.

And yes, you have to restart your x-session in order to have the new environment available for your desktop icons. Imagine such a startup scheme: Graphical Login -> Use your default shell to start the X session -> Desktop -> Shell terminal / Launch program via icon, so the child shells inherit the environment from the parent, which is used to start the X session. That shell read the RC-files only once -- on your login to the X session.

For the bonus point. This is what the manual says:

export [ name[=value] ... ] The specified names are marked for automatic export to the environment of subsequently executed commands. (...)

If you define your variable in ~/.zshenv, you can in principle omit the export as this file is read in by default. The only difference arises if you start a shell with zsh -f, which sources no RC files. A little demonstration:

% foo=foo_defined
% export bar=bar_defined
% print -l $foo $bar
foo_defined
bar_defined
% zsh -f
% print -l $foo $bar
bar_defined
% 

I. e. only the exported $bar is defined in subsequent shells. But to be on the safe side, use export -- I can't think of a case where this is harmful.

Solution 2

I don't believe that @mpy is correct that you can omit the export statement. The presence/absence of export determines whether or not processes launched from that shell will inherit the environment variable. If you don't export, xserver will not inherit the environment variable

 imalison  ~  ABCD='14'
 imalison  ~  python -c "import os; print os.environ.get('ABCD')"
None
 imalison  ~  export ABCD='14'
 imalison  ~  python -c "import os; print os.environ.get('ABCD')"
14

Comments

[user779159]

By default shell do you mean the one in /etc/passwd? Let's say someone uses bash as their default shell but has gnome-terminal configured to automatically open up in ZSH. In that case will .zshenv be read on startup? If not, is there a shell-independent file that can be used to place variables like this? (I know there's things like ~/.profile and ~/.pam_environment described at help.ubuntu.com/community/EnvironmentVariables, but how do those fit in with your answer of ~/.zshenv?)

[mpy]

@user779159 : Yes, by default shell I meant that one defined in /etc/passwd. zshenv is zsh specific, so is not read in by bash, csh or whatsoever. My answer applied only to zsh, according to your question tag. In an inhomogeneous setup (default shell other that gnome-terminal shell), the possibilities in your link seem sensible. I would put the variable in ~/.profile and made zsh in gnome-terminal a login shell by using zsh -l as startup command.

[Carl Walsh]

You're right, normally if you skip export then subprocesses won't see the variable. But if you're modifying a variable like PATH that has already been exported, so you don't need export.

[jenkizenki]

thank you for this @imalison, as this was the straw that fixed the camel's back ;) lol