I'm setting permanent environment variables from an NSIS installer like described in the NSIS wiki. That works as expected, the variable is available to new processes after the installation.
However, when using the option to launch the installed program at the end of the installation, the environment variable is not available for that program started from the installer. I assume this is because the program started there has the installer process as parent and gets the same environment block (see the lpEnvironment argument of the createProcess function).
How can I make the program started from the last page of the installer see the newly set environment variable? Writing a custom launch function instead? The documentation does not say anything about the environment block of the Exec function.
You also need to use the Setting Environmental Variables Temporarily code if you want child processes to inherit the (updated) environment because only explorer.exe responds to the WM_WININICHANGE notification.
outfile "test.exe"
name "run env test"
requestexecutionlevel user
!define MUI_FINISHPAGE_RUN "cmd.exe"
!define MUI_FINISHPAGE_RUN_PARAMETERS "/k set foobar"
!include MUI2.nsh
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
!insertmacro MUI_LANGUAGE "English"
Section
System::Call 'Kernel32::SetEnvironmentVariable(t "FooBar",t "BazBlargh")i'
SectionEnd
Related
In my rails application, I exported my database variables in .profile using ansible. the variables are accessible by the command printenv. However, when I run the application or use rails c via ENV['NAME'] , the variables aren't there.
Does anyone have any idea why rails doesn't load variables from .profile?
The ~/.profile script is only meant to be read by your (presumably POSIX compatible) shell. And even then only if it is what is known as a "login" shell. For example, from the bash man page:
When invoked as an interactive login shell, or a non-interactive shell with the --login option, it first attempts to read and execute commands from /etc/profile and ~/.profile, in that order.
If you're running your rails application from an interactive shell prompt it should have access to the env vars you're setting in ~/.profile. If you're starting your rails app some other way (e.g., from your window manager) then you'll need to find some other way to set the env vars that it inherits.
What exactly is the difference between these two operations?
source activate python3_env && python my_script.py
and
~/anaconda3/envs/python3_env/bin/python my_script.py ?
It appears that activating the environment adds some variables to $PATH, but the second method seems to access all the modules installed in python3_env. Is there anything else going on under the hood?
You are correct, activating the environment adds some directories to the PATH environment variable. In particular, this will allow any binaries or scripts installed in the environment to be run first, instead of the ones in the base environment. For instance, if you have installed IPython into your environment, activating the environment allows you to write
ipython
to start IPython in the environment, rather than
/path/to/env/bin/ipython
In addition, environments may have scripts that add or edit other environment variables that are executed when the environment is activated (see the conda docs). These scripts can make arbitrary changes to the shell environment, including even changing the PYTHONPATH to change where packages are loaded from.
Finally, I wrote a very detailed answer of what exactly is happening in the code over there: Conda: what happens when you activate an environment? That may or may not still be up-to-date though. The relevant part of the answer is:
...the build_activate method adds the prefix to the PATH via the _add_prefix_to_path method. Finally, the build_activate method returns a dictionary of commands that need to be run to "activate" the environment.
And another step deeper... The dictionary returned from the build_activate method gets processed into shell commands by the _yield_commands method, which are passed into the _finalize method. The activate method returns the value from running the _finalize method which returns the name of a temp file. The temp file has the commands required to set all of the appropriate environment variables.
Now, stepping back out, in the activate.main function, the return value of the execute method (i.e., the name of the temp file) is printed to stdout. This temp file name gets stored in the Bash variable ask_conda back in the _conda_activate Bash function, and finally, the temp file is executed by the eval Bash function.
So you can see, depending on the environment, running conda activate python3_env && python my_script.py and ~/anaconda3/envs/python3_env/bin/python my_script.py may give very different results.
I am new to lua script features.
I tried using,
os.execute("export MY_VAR=10")
io.popen("export MY_VAR=10")
from lua script.
I try reading MY_VAR variable from shell using echo $MY_VAR after lua script is executed but I do not see MY_VAR getting set to 10.
How do we set the environment variable using lua script?
Your problem isn't a lua problem. Your problem is misunderstanding how process environments work.
Every time you run os.execute or io.popen you are running a new process with new environment.
So while you may be correctly setting MY_VAR in that processes environment (and it would affect any processes run as children processes of that process) it doesn't survive beyond the death of the launched process and so cannot be seen by any other processes.
If you want to affect the lua process's environment (which would then, in turn, affect the environment's of processes run by lua) then you need a binding to the setenv system function (which lua itself doesn't provide as it doesn't pass the clean C test that lua uses for things it includes).
I have Installshiled script which define CATALINA_HOME as environment Variable initially. same script after that execute the batch file service.bat that is using CATALINA_HOME. this file when executed display the error CATALINA_HOME is not define define correctly. as this variable is defined as environmental VARIABLE and pointing Tomcat Directory Properly. I thing the system require reboot to recognize environment Variables.Is there any way to define Environment that work directly without reboot. I am using 64 bit Windows 7.
I may be wrong but the script that you're running loads the env variables once when you start it so you won't get any new env variables added during the runtime of the script.
And in your script, if you just execute the batch file, it will use the same out dated env variables the script started with.
What I do is run 'cmd /k service.bat' This starts a new shell (with the updated env variables) and runs the batch file and terminates afterwards.
You shouldn't need to reboot between your install.
I am looking at a user environment variable created using Windows console command
reg add "hkcu\environment" /v SARMaster_Server_Name /d %smServer%
This variable name SARMaster_Server_Name can be seen in the registry under HKCU/Environment with the correct value as well as through the advanced System settings of the Control Panel.
However, when I run
echo %SARMaster_Server_Name%
I get %SARMaster_Server_Name% instead of the actual value of this environment variable. What did I miss? All other environment variables such as TEMP can be echoed.
Variable is being set correctly using
reg add "hkcu\environment" /v SARMaster_Server_Name /d %smServer%
However, I need to restart to be able to access this variable. A workaround, which does not help in my scenario is to open the Environment Variables editor from the Control Panel and click on OK after the variable has been added using "reg add". Somehow, this action registers the new variable which can now be accessed on a new CMD session. Problem is being reported on XP so it may have been fixed on Windows 7 a