if i change hkey_current_user/environment/path in registry, get-env "PATH" doesn't reflect the new value unless I close rebol console and re_open it.
Environment variables are not the same things as Registry Keys.
Windows does consult particular registry keys when it is setting up the default environment a program gets when it launches from the shell. However, changing it won't inject those values into the environments of already running processes (in Rebol or any other program). Conversely, if you set things in the environment of a running program you won't see those changes reflected back into the registry.
If you want to read registry values, there is an API for that:
http://www.rebol.com/docs/sdk/registry.html
BUT rightly or wrongly: it is generally accepted (on every platform I've used) that one must exit a program and restart it in order to refresh environment variables from system settings. If you try and work around that, you may cause more complexity and confusion than anything else.
Related
We are using Pentaho Data Integration V7 working with multiple data origins with an Oracle DWH destiny.
We have stored all the connection access data in a parametrization table, let's call it : D_PARAM. All the connections are configured using parameters (${database_name} ... etc)
We have , at the begining of every job , a transformation with a "set variables" step which reads the right parameters from D_PARAM.
This all works fine, my problem is :
Every time we want to edit a single transformation, or in the development process of a new one , we can't use the paremetrized connections because the parameters haven't been setted. We need then to use "hardcoded" connections during the development process.
Is there a better way to manage this situation ? The idea of having the connections parametrized is to avoid errors and simplify the connections management, but if at the end we need both kind of connections.. I don't see them so useful.
There's not a simple answer, you could rotate your kettle.properties file to change default values, you keep all the values in the file:
D_PARAM = DBN
D_PARAM_DB1 = DB1
D_PARAM_DB2 = DB2
...
And just update the D_PARAM with the one you need from the different D_PARAM_DBN before starting PDI. It's a hassle to be constantly updating the kettle.properties file, but works out of the box.
You could also try working with environments, for this you would have to install a plugin available in Github: https://github.com/mattcasters/kettle-environment, it was created by a former PDI developer, and I don't know if it works with v7 version, it was updated to work with 8.2, but it would probably work with v7, to test it, you can install your PDI version on another directory on your PC and install there the plugin (and other additional plugins you have in your current installation), so you don't break your setup. This blog entry gives you details on how to use the environments: http://diethardsteiner.github.io/pdi/2018/12/16/Kettle-Environment.html
I don't know if the environments plugin would solve your problem, because you can't change the environment in the middle of a job, but for me, with the maitre script to use the environments when I program a job or transform, it's been easier to work with different projects/paths in my setup.
In Spoon you can click on the “Edit” menu and “Set environment variables”. It’ll list all variables currently in use and you can set their values. Then the transformation will use those values when you run.
Also works in Preview, but it’s somewhat buggy, it doesn’t always take updated values.
I am working on an iOS application that uses a pretty normal multi-environment deployment model. We have a QA, Prod, and "Dev" version of the app that all talk to their own corresponding backends. I am new to iOS development but am familiar with Node, Java, and a few other development environments.
The first thing I reached to for this problem was Environment Variables. I saw that XCode had a way to set environment variables in a Scheme and they could be read pretty easily. So I used 4 environment variables per environment to configure a few needed backend hosts. Everything seemed to be going fine until I realized that those environment variables seem to ONLY be available when running the app through XCode. Is that correct? Is there no way to configure environment variables that "bundle up" with an app? If so, the ability to configure environment variables at all seems like a footgun.
What I mean is, In a NodeJS or Java app, I can set a number of useful "necessary" configs like a backend hosts and use some approach to provide those values when running the app for real. It seems like in iOS / Swift, environment variables are only useful for development-time debugging settings? The asymmetry between what's available in XCode vs a "real" shipped app seems odd.
Is there a similar standard way that I can configure my app for multiple different environments that works on shipped applications and ideally just involves reading some value at runtime rather than using conditionals and/or using compiler flags or something?
You are correct. The Environment Variables are only meaningful when executing the Scheme in Xcode. Their primary use in that context is to activate debugging features that are not on all the time. For example, if you try to create a bitmap Core Graphics context (CGContext) with an invalid set of parameters, the debugger may tell you to set an environment variable to see additional debugging output from Core Graphics. Or you can set environment variables to turn on memory management debugging features.
When you are running an application on a server, the Unix framework in which the application is running is part of the "user experience". In that context it makes sense for the application to use things like environment variables.
As developers we understand that a mobile app is running inside a unix process, but that unix environment is mostly unavailable to us. A similar feature that is common to Unix apps is command line arguments. An iOS application on startup receives command line arguments (argc and argv) but there is no way specify those when the app is launched either.
There are a number of places you could include configuration information like that which you describe in your application. The most common that I can think of is to include the setting in the applications Info.plist. At runtime you could access the contents of the property list by fetching the main bundle and asking for it's infoDictionary:
let infoBundle = Bundle.main.infoDictionary
let mySetting = infoBundle["SomeSetting"]
When the application's info.plist is created, it DOES have access to the environment variables declared in the Scheme so you could put the environment variables in the scheme, reference them in the Info.plist, and retrieve them at runtime from the main bundle.
try Using FeatureFlags, maybe will help you, check this
https://medium.com/#rwbutler/feature-flags-a-b-testing-mvt-on-ios-718339ac7aa1
I'm new on this technology (studying for now) and I have a doubt on how to properly work with the Apps.
For example, I have an app-gateway with 2 instances (Traefik), and in there I'm using env variables like RESTRICTED_NETWORK_01 and RESTRICTED_NETWORK_02.
I want to replace de IP value of RESTRICTED_NETWORK_02 and apply the change without any impact to the gateway/redirect users service.
Should I just use the command:
cf set-env app-gateway RESTRICTED_NETWORK_02 [ipvalue]/24
then
cf restart-app-instance app-gateway 0
wait until the instance restarts and apply
cf restart-app-instance app-gateway 1
Is it the right steps I should follow for this situation?
Any help?
cf restart-app-instance app-gateway 0
This will probably not do what you want, at least not reliably. This command works by terminating your application instance, which then allows it to be restarted. It's typically useful if you have an app instance that's in a bad state but hasn't crashed or failed health checks (or for demos where you need to make an app crash).
In terms of env variables, it doesn't work so well. This is because the env variable changes you've made reside in Cloud Controller, but your application runs on the scheduler (Diego). The scheduler has a copy of data from the Cloud Controller that tells it how to run the app, including environment variables that should be set. The command you're referencing doesn't result in Cloud Controller updating the application definition that it has sent to the scheduler (Diego). It simply results in the process being terminated and restarted by the scheduler using the same definition.
Your mileage may vary on this one, as I've heard some reports of people saying that cf restart-app-instance works for updating env variables (I don't really see how it would, but I haven't investigated their claims either). You could try it and see, but the stories I've seen have typically ended with problems. tl-dr it doesn't consistently work.
To reliably update env variables, you need to use cf restart. This will restart all application instances.
What you should do to restart app instances without downtime is to use the cf restart --strategy=rolling option (available in version 7 of the cf cli). This will roll out the changes and so long as you have multiple application instances, should not result in downtime.
I have a problem assessing my advanced settings of my computer, anytime i get to the properties of my computer it freezes and vanishes, I decided to set my path through the command prompt. Though the lines below works. Its just temporal and the path is unset immediately i close the running command prompt,
set path=%path%;C:\python27
I am just wondering why my computer's property panel vanishes.
Any others ways to set the environment variables permanent?
try using setx PATH "%PATH%;C:\python27"
Note that u need to close the current cmd window, after executing this command as the changes will reflect in newer instances only.
background info;
an application is installed on many different PCs, W2000 and XP pro and for multiple users, let's call it foobar, note there is no msi or silent uninstall for this app. therefore, we would like to remove its' entry manualy;
If in the registry environment (path line) we have path=c:\windows;c:\windows\system32;c:\foobar\bin;c:\foobar\bat;c:\c:\oracle\bin
how would we, from the command line, change that line to path=c:\windows;c:\windows\system32;c:\c:\oracle\bin
each path line might be different but c:\foobar\bin;c:\foobar\bat; has to be deleted on all machines.
My thought,
export registry env setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment and remove the unwanted items from there and reimport. Easier solution??
To permanently change the PATH use
Control Panel, System, Environment, System Variables
Control Panel, System, Environment, User Variables