export creates a global environment variable?
 

So, until now I knew that export is creating a global environment variable that can be accessed by any process. But I tried the following and it didn't work.

I opened a terminal and typed Then I echoed it and got 1.

Then, I opened a new terminal and typed . The result is an empty line instead of 1.

Why is that? In my ~./bashrc script (provided by my Linux distribution Arch Linux) I have the following exports:
and they work globally (I tested them by echoing them in different terminals).

Why this works in the bashrc script and not in the way I described at the top of this post?

Thank you.

~./bashrc is used every time you open bash terminal.
Put export a=1 in ~./bashrc

In one terminal enter
Open another terminal

Ohh. Now it makes sense. So what is the difference between and ? I think one time I tried something like this:

where myapp creates a new thread which uses the LIBGL_ALWAYS_SOFTWARE variable. But the above example didn't work, while the one below worked:

It does this only for the currently running shell. Which ends when you close your terminal, and is not connected to another shell opened in another terminal.

There is, however, something called a login shell, which parses various startup files (e.g. ~/.bash_profile if you're using bash). It's some kind of Uber-shell. I'm sure somebody will be along shortly and give you the technical details. Or you could perform a web search.

The latter is a pure local variable for that shell only, the first will be inherited by all programs that are started after that export has been done (so all children, run in that specific shell).
BTW: you can export a variable even before setting (or changing) it, but afterwards too.
So both as well as are legal. Sometimes you do not even have to export at all, like i.e. PATH, TERM, they have already been exported by the shell, but you can locally change their value.

Once exported, the variable stays in the enviroment.

When you opened the new terminal, you created a fresh new environment based on the one created when you logged in and your GUI was started. Create another terminal and you created another fresh environment. Without doing anything, those two environments will be the same. But once you start creating new variables, exporting them, etc. in one terminal, those environments begin to differ and changes in one are not reflected in the other.

Does that make sense?

It'd sure be nice if I could make a change that I'd like to be "global" after I've already opened terminals and applications in ten different activity windows without havng to log out and back in again but UNIX/Linux doesn't work that way. All you can do is plan ahead: make the change in whatever defines your environment at login and it'll be there when you login the next time in all the terminals you open up.

HTH...

Everything makes sense now guys. One last thing. The first program that starts inside a terminal, for example:
it is also a child of the bash's process right? What I want to say is that it starts a new process instead of living inside the bash's process as a thread (probably this is a stupid question, of course, it starts a new process). I need to export myvar so that myapp can read it, right?

Any "real" executable (binary) will be a new process.
A shell script can be run either by a new (child) instance of the shell (or a different one, if you used #!/bin/<someshell> as its first line) OR by the current shell itself. In that case the alternate shell line is ignored, and you have to start it asThe latter posibility makes it possible to alter the environment OF that shell itself and is the way .bashrc and .bash_profile startup scripts are run.

True.
A workaround is to make such a change in "whatever defines your environment at login" (e.g. ~/.bashrc) in one terminal and then source it:
in other, already opened, terminals to effect the change therein without logging out.

yes.