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.

Improve this question
7
  • 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? Commented Jul 20, 2012 at 23:16
  • Gnome and Unity(i think) - Default Ubunutu 11.10. How can I check this? Commented Jul 21, 2012 at 7: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. Commented Jul 21, 2012 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. Commented Jul 21, 2012 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. Commented Jul 22, 2012 at 13:54

2 Answers 2

Reset to default
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.

Improve this answer
10
  • "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? Commented Jul 22, 2012 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 Commented Jul 22, 2012 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. Commented Jul 22, 2012 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. Commented Jul 22, 2012 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. Commented Jul 22, 2012 at 20:42
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.

Improve this answer
1
  • 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. Commented Jul 21, 2012 at 21:18

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.