I have read tons of posts about how you can't set persisting environment variable in a child script of a shell and have it persist. The only way is to source a file as
% . <scriptname>
I am finding that true... but I know there is a way around it. I just don't know how. I worked for 6 years at a company where you would set a bunch of environment variables that defined your work space with various tools. They were all very simple to use ex.:
% toolname argument
% echo $envVarFoo
% Bar
These variable drove everything about what directory you were in, how other tools behaved, and where your files were written to and read from. And there was nothing hacky/tricky for the user.
Shame on me for not better examining the tools, though they were extremely complicated. I do know they are made up of some Perl and Python mostly. I am writing a sweet of tools now to do various things. One thing I need to be able to do is set environment variables that don't die with the script. Can someone please point me in the right direction?! I know we didn't litter our system with hidden dot files either.
IF you source a script the environment variables persist. A sourced script should not call exit or you will be logged out.
Two ways to source a script named env.sh
. env.sh
source env.sh
Those tools probably had you running inside a child process, with the parent process killed off. So when you exit the now-current child process, you log out.
Another more sensible approach: In C/perl you can all exec to run a command like "bash -c env.sh" to set variables. Which is probably what the perl code did. This does not create a child it replaces the old process. This is also what sourcing does.
I faced similar issue while i was developing tools for navigating to different directories, I wrote script to change user CWD to desired one (from the inputs provided) but as script used to run in sub-shell it used to bring user back to original directory!!
To avoid that i created functions, here is sample code .. (writing directly here..)
$ cat chageDir.sh
newDir=$1
cd $newDir
$ function changeDir {
. Path/to/script/changeDir.sh $@
}
changeDir /tmp
by creating function, you can avoid writing ". /" or "source", good from user point of view... also function allows sending arguments. If there are no arguments just use alias!
So jim, when you use "bash -c env.sh" to spawn a new shell, is there a way to make that invisible to user? currently it changes the user name or computer name on the left to "bash:" Can that be avoided?
And to zedex, what you cat "changeDir.sh" where does that file get stored? is it in the current directory or into memory? I don't want to litter .sh files everywhere
There's nothing mysterious about it -- it's just the value of the PS1 variable being changed or, perhaps, being left blank. Try 'export PS1' before running it so things you run can inherit it. Or you can always change it to whatever you want later.
