[solved] UpdateEnvironment

[SisterOfMercy]

I have an issue with reading an environment variable. This happens when installing java-runtime, and a different package with a dependency on java-runtime.

In the java-runtime package an environment variable is set like this:

Code: Alles auswählen

openkey [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment]
set "JAVA_HOME_x64" = "$InstallDir64$\bin"

pdfsam, for instance, is a java application and uses it to create a shortcut:

Code: Alles auswählen

[LinkFolder_install_64]
set_basefolder common_programs
set_subfolder ""
set_link
	name: "PDFsam"
	target: "$JAVA_HOME_x64$\javaw.exe"
	parameters: -Xmx512M -classpath .\lib;.\pdfsam-basic.jar -Dapp.name="pdfsam-basic" -Dprism.text=t2k -Dprism.lcdtext=false -Dapp.home="." -Dbasedir="." org.pdfsam.basic.App
	working_dir: "$InstallDir64$"
	icon_file: "$InstallDir64$\pdfsam.exe"
	icon_index: 0
end_link

When pdfsam is installed directly after java-runtime the variable is either not existent or an old value.
So I tried to update the enivornment, with UpdateEnvironment, like is said in the manual:

Code: Alles auswählen

	Registry_install_64 /64Bit (here is where the registry gets modified like above)
	comment "Reload environment variables"
	UpdateEnvironment
	Winbatch_Update_Environment /64Bit /RunElevated

[Winbatch_Update_Environment]
"%ScriptPath%\files\nop.exe"

However, it does not seem to be working. If I change the environment variable to something else, then on a restart (and installation of java-runtime and pdfsam) the pdfsam script still reads the old value.
Of course java-runtime is installed before pdfsam.

[wolfbardo]

UpdateEnvironment

http://download.uib.de/opsi4.1/stable/d ... nvironment

"Sends Windows the signal to reload the environment values from the registry. This statement may be called after any rocess that may have changed the environment (e.g. Registry section or setup program). Even if the program that runs after the opsi-script get the new environment, the next process that is started (via DosBatch or Winbatch) from this opsi-script instance will still inherit the old environment."

Especially the running script runs with the old environment and also any process started from this script.
You can try if its works to run a subsequent winbatch elevated, cause this new process gets an new environment

regards,
bardo wolf

[SisterOfMercy]

Especially the running script runs with the old environment and also any process started from this script.
You can try if its works to run a subsequent winbatch elevated, cause this new process gets an new environment

Oooh, I thought the new environment would be loaded after a new winbatch /runelevated, but that is only valid for that particular /runelevated instance.

[SisterOfMercy]

But eh, shouldn't opsi reload itself after an UpdateEnvironment call?
I see the WM_SETTINGCHANGE call in the code, and I see it working in an elevated winbatch.

Of course, there are a couple of workaround; Rebooting after setting a environment variable. Or reading the environment variable from the registry.
I'd still be nice to have UpdateEnvironment expanded. The number of reboots is increasing :-p