Posts: 37,098
Threads: 2,599
Joined: May 2025
Reputation:
0
i'm successfully setting environment vars in the terminal but if i open a new window and echo said var, its not shown. a quick google search implies that "export" should do this.
the idea is to have a variable that persists between running applescripts.
suggestions?
Posts: 5,314
Threads: 111
Joined: May 2025
Each time a terminal window is opened, there is no inherited environment from the Finder. The command shell (bash/tcsh/ksh/csh/sh) is a 'login' shell and gets special treatment. Each time you run a command (including a subshell) in a shell, the parent shell's environment is copied to the child command's environment. This is a one-way transfer, from parent to child.
The easiest way to push environment vars to another login shell would be to write them to a file that the new login shell would see when it starts up. Different shells have their own startup files that are executed once only at 'login':
sh, ksh: $HOME/.profile
bash: $HOME/.bash_profile
csh, tcsh: $HOME/.login
Command shells have other startup files that are read by all shells (login & descendants):
ksh: $HOME/.kshrc
bash: $HOME/.bashrc
csh: $HOME/.cshrc
tcsh: $HOME/.tcshrc
You have shell A that wants to set some environment variables for shell B (not a descendant of shell A) to see when it starts.
1. Modify each of the shell startup scripts (.profile/.bash_profile/.login) to test for a readable file and then source it. The file will contain environment variable setting commands. The file could be in the account home directory, named .{shellkind}env:
sh/ksh/bash: $HOME/.shenv
csh/tcsh: $HOME/.cshenv
in sh/ksh, the test would be in $HOME/.profile, in bash use $HOME/.bash_profile:
# any preloads for my environment?
[ -r $HOME/.shenv ] && . "$HOME/.shenv"
in csh/tcsh, it would be in $HOME/.cshrc :
# any preloads for my environment?
if ( -r "$HOME/.cshenv" ) then
source "$HOME/.cshenv"
endif
2. in login shell A, create your variables in the environment. As you do so, add them to the $HOME/.{shell}env file, as commands to be read and executed by login shell B:
in A (works for sh/ksh/bash):
# empty out $HOME/.shenv (just once)
echo "" >"$HOME/.shenv"
# create new variable put in the environment
FOO=newvalu ; export FOO
# add it to the $HOME/.shenv file
echo "FOO=newvalu ; export FOO" >>"$HOME/.shenv"
# repeat the create & add for other vars
in A (works for csh/tcsh):
# empty out $HOME/.cshenv (just once)
echo "" >"$HOME/.cshenv"
# create new variable put in the environment
setenv FOO newvalu
# add it to the $HOME/.cshenv file
echo "setenv FOO newvalu" >>"$HOME/.cshenv"
# repeat the create & add for other vars
3. whenever you startup a window for login shell B (or C or D ...), the login shell will read and process the environment setting commands in the .{whichever}env file and each of its child processes will have a private copy of the parent shell's environment (including the new vars).
4. It is possible to write a single file that can be sourced by any shell and that can test which shell is executing it, and feed the proper environment setting commands to that shell. Not easy, but possible.
5. You really don't want a bunch of shells running thinking they are type A, willy-nilly trashing the $HOME/.{whatever}env file and overwriting with their current favorite values. Especially while poor old type B shells are trying to read and process the same file.
6. The use of double quotes around $HOME/.filename is intended to deal with embedded spaces in the value of $HOME
7. When you are through with the contents of $HOME/.{whatever}env, you can remove it. The next login shell will simply note the file does not exist, and skip on to the next command in its startup script.
HTH,
Posts: 5,314
Threads: 111
Joined: May 2025
Oops, in my 'answer' at the end of part 1, I wrote
[quote TheCaber]
in csh/tcsh, it would be in $HOME/.cshrc :
That should be $HOME/.login
.cshrc is read by every csh or tcsh shell whether login or not.
You want only the login shell to process the contents of .cshenv