5

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?)

user779159
  • 259
  • 2
  • 5
  • 9

2 Answers2

6

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.

mpy
  • 27,002
  • 7
  • 85
  • 97
  • 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 https://help.ubuntu.com/community/EnvironmentVariables, but how do those fit in with your answer of ~/.zshenv?) – user779159 Jan 31 '14 at 11:29
  • 1
    @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. – mpy Jan 31 '14 at 11:40
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
imalison
  • 131
  • 2
  • 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`. – Carl Walsh Jul 26 '20 at 02:05
  • thank you for this @imalison, as this was the straw that fixed the camel's back ;) lol – jenkizenki Sep 26 '20 at 20:31