4

How can I change environment variables without re-logging to UI?

I want to re/define some variables and want them set on my current logged in shell (including UI). I know logging out and then logging in again would work, but I want to test it right away - without re-logging in. How can I do that? (If I can). Thanks.

AlikElzin-kilaka
  • 561
  • 1
  • 8
  • 20
  • To affect one running shell, run `. ~/.profile`. To affect newly launched GUI environments, it depends on your window manager or desktop environment. What WM/DE do you use? – Gilles 'SO- stop being evil' Jul 20 '12 at 23:16
  • Gnome and Unity(i think) - Default Ubunutu 11.10. How can I check this? – AlikElzin-kilaka Jul 21 '12 at 07:00
  • Another way to do it is to use `export`, and then simply launch a new shell. E.g., `export EDITOR="nano"` and then `bash`. Probably this will not work for everything, and in general, `source`/`.` seems more robust, but it can be useful to know. – Emanuel Berg Jul 21 '12 at 18:32
  • As user1129682 wrote in one of the answers below: *This may change the environment of the current shell process, yes, but it does not change the environment of other running processes, especially the running gui.* – AlikElzin-kilaka Jul 21 '12 at 21:24
  • @kilaka: Do those processes get a copy of the environmentals at initialization, or do they get references to - say, shared memory (a way of IPC)? In the second case, they should be affected if the parent process changes a variable. I realize you probably didn't wrote the GUI elements; still, it may be interesting to think about. – Emanuel Berg Jul 22 '12 at 13:54
  • @EmanuelBerg: I'm talking about defining new variables so that when running a new app or non-login shell - they'll get the new defined variables. Again, without logging out and back into UI. – AlikElzin-kilaka Jul 22 '12 at 15:13
  • @kilaka: When you *run* them from the shell, and the shell has the variable values you'd like, aren't the new processes (just run) doing so with the new variable values? But, if the processes are *already running*, and you do not wish to restart them to affect them, doesn't that mean you would have to use more advanced methods like inter process communication, IPC? This is how I would examine the problem, but more than that, I can't help you because I never had a situation like yours. But when you solve it, pleas tell us how. – Emanuel Berg Jul 22 '12 at 15:25

2 Answers2

1

This has been bugging me as well and I took your question as catalyst to investigate a little myself. Apparently you can't/shouldn't.

There is a similar question on stackoverflow which has only using gdb as the accepted solution. The other answers suggest (and I concur if you care) that changing environment variables after gui startup has little to no effect. Especially as changing the environment of a process does NOT AFFECT the environment of its children.

Community
  • 1
Bananguin
  • 7,796
  • 2
  • 25
  • 57
  • "Especially as changing the environment of a process does NOT AFFECT the environment of its children." Is it really always like that, it couldn't be tweaked somehow with `fork` flags or - maybe even message passing as a last resort? – Emanuel Berg Jul 22 '12 at 15:28
  • I'm sure you can make it work, but after a process is forked it has its very own environment, b/c it's a copy (!) of the parent. So without further hacking changes don't propagate along the process family-tree – Bananguin Jul 22 '12 at 16:04
  • I think shared memory would be optimal because then you would only have to change the forking part, not the setting of the variables, in the parent (i.e., otherwise you'd have to hook "set variable" to a send invocation to the children). Also, then the children would not have to receive messages and do updates; they could read as usual from the variables. Note that this is theory: I don't know how to do it in practice but I'm sure it'd be more difficult than I make it sound. – Emanuel Berg Jul 22 '12 at 16:16
  • Yes it probably is. But there's a better question: why would you want to change the environment of EVERY child process of a given process at runtime. This does sound a lot like inter process communication to me and for that there are other facilities. Using those appears more sensible. – Bananguin Jul 22 '12 at 17:33
  • Well, that is perhaps a personality thing. Some people search for the "optimal" solution. Me, I look for **any** solution - whatever the outcome, you will gain experience and knowledge. As for IPC, shared memory is just that, along with semaphores, mutexes, named pipes, and more. It isn't hard to imagine why you would want it to work the way you describe: for example, to configure your GUI. You change in one place, and then see the outcome instantly in all GUI elements. But, to tell the truth... There are some **experts** of Unix C in this forum, I hope they will have their say about this. – Emanuel Berg Jul 22 '12 at 20:42
  • It doesn't work like that. There may be sensible appications for that, but in most cases this is probably a bad idea! Good application: you add a remotely mounted directory to (the end of) your PATH so that you have more programs available. Bad application: you prepend a directory to the LD_LIBRARY_PATH with different versions than your OS and as a result you get a probability that every running process loading a new library crashes due to incompatibility. Sharing environments can have so many side effects that you don't want a generic approach. – Bananguin Jul 23 '12 at 07:09
  • OK then, not using IPC, how would you do it? – Emanuel Berg Jul 23 '12 at 09:44
  • Use IPC to transport the actual information, not to change the environment. IPC is not a/the problem. Recursively changing environments of arbitrary processes/programs is the bad idea. You need a more clearly defined problem and a solution to that one problem. Using the big hammer on this problem is more likely to break your UI than to do something useful. – Bananguin Jul 23 '12 at 14:15
  • OK, I see what you mean. – Emanuel Berg Jul 23 '12 at 15:08
  • @user1129682 The problem is changing an environment variable in the GUI session and make everything behave as if you re-logged-in - from that point on - without re-logging-in. – AlikElzin-kilaka Jul 26 '12 at 08:50
0

Use the 'source' command in the terminal. For example if you have a shell script which defines some variables you can do

source my_script

to (re)load the variables into the environment.

If you use bash then the following shorthand also works:

. my_script

This is also a good way to reloading files like .bashrc.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
  • 3
    This may change the environment of the current shell process, yes, but it does not change the environment of other running processes, especially the running gui. – Bananguin Jul 21 '12 at 21:18