0

I would like to create the variable $EIGENto save the path where I installed the Eigen library in order to link in with my compiler. For this I was using set EIGEN path/to/eigen

However if I echo $EIGEN in another shell there is no output.

3
  • Just for clarity -- You have this tagged as "Fish", so I've answered based on that shell. But it is unclear in the question if you mean that you want to set it in one fish shell instance and have it take effect in another 'fish shell, or if you mean that you want to have it take effect in a bash (or other) shell. Commented Sep 3, 2021 at 12:53
  • Also it would be useful if your question included the command you are currently using to set the variable. Commented Sep 3, 2021 at 12:56
  • That's not how environment variables work. They are not global. They are private to each process and inherited from the program that started it. Yes, one of the answers shows how to use fish's universal variable feature. I don't recommend using it for environrmental variables. Commented Sep 3, 2021 at 17:33

2 Answers 2

2

If you want a variable to be set for every shell launched then you should edit the default profile.

By default that file is located at ~/.config/fish/config.fish, where ~ is your user home directory. If you do not have that file then you should create it. In that file you can enter the same command you used to set the $EIGEN value in your normal shell.

You can find more at Fish Shell FAQ

If you need to set the value for every program then you should consult the documentation for your operating system which should tell you how to set environment variables globally.

0
0

Short answer:

set -Ux EIGEN /path/to/eigen

Explanation:

One of the differentiating features of Fish is the ability to set a "Universal Variable" that is:

  • Persistent
  • Immediately available across all shell instances

The -U creates a universal variable, with the -x marking it as exported.

Note that if you already have set $EIGEN in another shell instance, that "local" or "global" variable will override the universal one.

Here's a pathologic, over-simplified example:

> set EIGEN /bad/path/to/eigen
> set -Ux EIGEN /correct/path/to/eigen
> set --show EIGEN
> echo $EIGEN
/bad/path/to/eigen
> set --show EIGEN
set: Universal variable 'EIGEN' is shadowed by the global variable of the same name.
$EIGEN: set in global scope, unexported, with 1 elements
$EIGEN[1]: |/bad/path/to/eigen|
$EIGEN: set in universal scope, exported, with 1 elements
$EIGEN[1]: |/correct/path/to/eigen|

Also, it's not quite clear from your question whether you mean something like this, starting in fish:

> set EIGEN /path/to/eigen
echo $EIGEN
/path/to/eigen
bash
$ echo $EIGEN
# No output

That wouldn't even require a universal variable, just an exported one. By default (in most any Linux/Unix shell), variables are set only for the current shell. New processes created from that shell don't see the variable. To make it available to subshells and other launched processes, it needs to be marked as exported. I'm going to switch to bash here as an example since we already demonstrated above how to mark it exported in fish. As above, I'll use $ to represent the Bash prompt and > to represent Fish:

$ EIGEN=/path/to/eigen
$ fish
> echo $EIGEN

> exit
$ echo $EIGEN
/path/to/eigen
$ export EIGEN
$ fish
> echo $EIGEN
/path/to/eigen
5
  • FWIW, using fish's universal variable mechanism for setting environment variables is a bad idea and tends to cause problems. If nothing else it makes novices incorrectly think they can affect the environment of arbitrary processes. This can only be used to affect the environment of other fish processes. Also, the way uvars interact with the other scopes can be confusing since uvars are only used if no var of the same name is set in any other scope; e.g., the global scope. Commented Sep 3, 2021 at 17:35
  • @KurtisRader Agree with the caveats, but did try to cover those in the answer. For the use-case mentioned here, though, it seems like the right approach. Commented Sep 3, 2021 at 18:42
  • @ NotTheDr01ds Yes, your answer appears to address most of my concerns. Nonetheless, you are encouraging the O.P., as well as others who stumble across your answer, to use fish uvars for this purpose. I've been programming since for a living since 1979, was a senior software engineer at Google, and used (and contributed to) fish for several years. Arguments from authority are weak but in this instance I think I'm on sound footing to discourage fish env uvars. :smile: Commented Sep 4, 2021 at 5:18
  • Thanks @KurtisRader - I've seen you mention that before on older Github issues, but I couldn't find the why behind the statements. Can you provide a link so that I can learn more? I know the team has done some fixes in that area in the recent past (3.2, iirc). Any idea if those address your concerns? Commented Sep 4, 2021 at 5:30
  • I switched from Fish to Elvish ~3 years ago so I have not been tracking changes since that time. However, any changes to improve the behavior of universal env vars would have to be backward breaking and thus require a major release. So it seems unlikely that the current release has addressed the problems. The uvar mechanism is really only useful for global vars that affect the behavior of fish; e.g., the colors used in prompts. So that if you can override the uvar by doing an explicit set -g. Commented Sep 5, 2021 at 1:59

You must log in to answer this question.

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