Hi,

What I am trying to figure out here is how to create an environment variable that persists across multiple terminal prompts. I can do that (sort of) by adding them to ~/.bashrc file (and/or /etc/profile) but I'd like to be able to change these variables on the fly, open a new terminal and have the variable exist with the new value. Is that possible? I THOUGHT that was what export did but apparently It's not.

Heres an example of what I'm doing (or trying to do).

This command will give me the mac address of ath0
So i have this in /etc/profile and ~/.bashrc

(I have many wifi cards or i would just hard code the mac)

So... if I open a terminal after logging in... and , it prints my mac address to the screen.
Now if run the following command... (notice it is ath1 now)

The value of WIFIMAC is now ath1's MAC address... so far so good.

BUT... if i open a new terminal window and ... the value is that of ath0 because that is what is in /etc/profile and/or ~/.bashrc

hopefully this all makes some kind of sense :-)

any insight here would be greatly appreciated.

Thanks!

Environment variables that are 'exported' propagate down to child processes. Therefore, if you want to launch a new terminal, and have the desired environment variables exist, you will need to launch said terminal as a child of the shell that contains the environment variables. If you are using xterm as your terminal, you can do this by typing 'xterm' at the command prompt, and it will launch an xterm containing a shell with the desired variables. Same applies for other terminal emulators.
--- rod.

Hi tehNbomr. Thanks for the response but I can't get that to work either.

I opened a prompt and checked $TERM... it is indeed xterm so i changed WIFIMAC and exported it like so...
then i typed xterm and it spit out the followingIt did open a new xterm (that looked completely different than the parent window) but it ties up the parent terminal window until its closed and when i tried to echo $WIFIMAC... it was nonexistant

Update: It is actually Konsole... but the problems are all the same.

Your child terminal can be launched in background mode:
As to why your exported variables are not appearing in the child processes, I can only guess that either you have made an error in setting or testing for your variable. Or, there is some script buried in the chain of bash startup scripts that clears (unsets) all variables except some set that it likes. Tell us what flavor of Linux you are using, and perhaps someone familiar with it will tell us whether that distro has such a configuration.
--- rod.

ahhh konsole& i KNEW that too lol

but just the same, The variable problem persists. I am primarily trying to get this to work on Backtrack2. Everything works just like you explained on Ubuntu 7 though so maybe it is an issue with BT2?

OK, so apparently the problem is with the variables being set in ~/.bashrc and/or /etc/profile

The variables are reset to the original value from one of these files every time a new terminal is opened (regardless of where or how it was opened)

So i have WIFIMAC set in /etc/profile and ~/.bashrc and if I open a terminal and type...
and then echo $WIFIMAC in the new terminal... I get the ORIGINAL value that is set in the profile files. if I do the same with a new variable that DOESNT exist in those files like...

then echo $TEST in the new terminal... it persists and displays "TESTING"

I guess it makes sense... I just won't be putting the variables in the .bashrc or /etc/profile

Thanks for helping to set me straight on what exactly export does. You've been a great help.

Cheers

+

bashrc is not source by login shell

eg:
su -
will not source /root/.bashrc

"It's a feature"

You mean it won't include the users environment? yeah But that just makes things more complicated

I mean that everything in the .bashrc will not be even read by bash for login shells. Environment variables or redirection or whatever from profiles will be kept yes.
It's a nice feature, I used it for increasing my post count of something like 20 posts on LQ because nobody's aware of this
One more

I guess I'm ahead of the game then cause I knew exactly what 'su -' was

Good luck with your quest to post more heh

nx5000
It's never been really clear to me what constitutes a 'login'. If I launch xterm from a bash commandline, it starts up an xterm with a bash shell running in it. The (new) bash shell is running as a child process of the xterm, which is a child process of the (original) bash shell in which I entered the 'xterm' command. What make the child bash process a 'login' (or not)?

I always lose track of what bash startup scripts execute & when, but is there not at least one script which is sourced each and every time bash starts? Is there a way to force bash to source one or more scripts on startup? If so, perhaps the original poster has some alias set which causes it to do so, invisibly. I really can't see very many ways that an arbitrary environment variable can be 'deleted'. Environments are not just a shell concept, but apply to all processes. As such, it seems strange that variables are disappearing.

--- rod.

PS Consigliere: What is Backtrack2?

It's not so clear for the users, that's why sometimes you have this in distro-default .profile:

I suggest you look at the man page of bash, the part INVOCATION.
There are so many exceptions that it would take me long to explain.
When you login to your machine, you get a login shell.
You can mimic this:
sudo login
enter user/pass
echo $0
-bash the - means login shell. Login shells will parse the profile files.
the next shells will be by default non login shells.
They will inherit from the login shells the ENV variables.
And they will source .bashrc
When you open an xterm from xwindow, you open a nonlogin shell.
If you want to keep track of whats happening, you can add a line like this:
echo "Sourcing bashrc" | logger
at the start of .bashrc
You will get the message in /var/log/messages

Why not just do

in ~/.bashrc to set WIFIMAC only if it isn't set already. Thus, resetting it on the command line will persist into subshells.