New post
Discussion (10)3
Log in or sign up to continue
Stefano Cairoli · Jun 19, 2019

My understanding is that while you can easily retrieve environment variables visible to your process using the $system.Util.GetEnviron() interface, you simply do not have access to an equivalent $system.Util.SetEnviron(), as setting of environment variables can be quite tricky, risky and very OS specific.

If you do absolutely need to be able to change an environment variable for your running process, and you are dealing with one specific platform, you can probably create your own $ZF("SetEnviron",var,value) code, based on OS specific calls like the Linux system service setenviron()..

Again: the short answer would be that out of the box you will be able to read but not set environment variables.
If you really do have the need of setting them, you would need to look into building the necessary $ZF call-out interface based on your target OS.

HTH

1 0
Rubens Silva · Jun 19, 2019

Are you trying to execute some binary outside Caché or is it related to your current Caché process? By the type of the value you used as example, I'm attempted to say it's related to the JVM. If so, you can set most of the values using the its command-line arguments, including the heap size.

If that's related to your current process, you could trying doing the inverse procedure and capture the values from a .env file instead, it seems you can't get freshly set env variables because for the OS the Caché is already a running process. Maybe you can work around it using by source 'ing a script file that sets it, but I haven't tried.

However, I'd still go with the .env file instead. I did a little utility sometime ago because I thought it would be useful someday

0 0
Rubens Silva · Jun 19, 2019

That's the issue. You can't read any new environment variables after the Caché/Ensemble process (by that I meant at OS level, using a shell script) has been started. Not even Docker allows you to do that, since you must rebuild the container to "refresh" the variables. Otherwise that would be a security flaw as @Stefano Cairoli pointed out.

If you own the code, you can try simulating env variables by using globals, which is exactly the same thing the class Sample.Installer does or populate it from an external file, like a .env. Also $zf won't work because it always summons a new shell to execute your call, so even though the variables you set would be available there, it won't be there for your current process (again, OS level).

0 0