How to set environmental variables from code in log4cplus so that i can use them in configuration files and update it at run time?
This is not log4cplus specific. Use whatever your OS/API provides: setenv() or SetEnvironmentVariable().
Related
setx does not set variables in the current environment. I want to set an environment variable and immediately use it. Can this be done? thx.
Does anyone know how to automatically set environment variables when activating an env in conda?
I have tried editing */bin/activate, but that adds the new environment variables for every new env that is created. I want to set env variables that are specific to each env.
Use the files $CONDA_PREFIX/etc/conda/activate.d and $CONDA_PREFIX/etc/conda/deactivate.d, where $CONDA_PREFIX is the path to the environment.
See the section on managing environments in the official documentation for reference.
Environment Variables as Configuration Settings
Conda v4.8 introduced a new command-line interface in the conda-env tool for managing environment variables on a per-environment basis. The command is conda env config vars and here is the help description as of v4.8.3 for the command overall:
$ conda env config vars -h
usage: conda-env config vars [-h] {list,set,unset} ...
Interact with environment variables associated with Conda environments
Options:
positional arguments:
{list,set,unset}
list List environment variables for a conda environment
set Set environment variables for a conda environment
unset Unset environment variables for a conda environment
optional arguments:
-h, --help Show this help message and exit.
examples:
conda env config vars list -n my_env
conda env config vars set MY_VAR=something OTHER_THING=ohhhhya
conda env config vars unset MY_VAR
Perhaps a bit verbose, but it avoids having to manually manage files in etc/conda/(de|)activate.d.
YAML Specification
Added in Conda v4.9, there is now support for automatic defining of environment-specific variables as part of an environment YAML definition. For example,
name: foo
channels:
- defaults
dependencies:
- python
variables:
MY_VAR: something
OTHER_VAR: ohhhhya
which would set up the environment variables MY_VAR and OTHER_VAR to be set and unset on environment activation and deactivation, respectively.
The accepted answer (conda/activate.d and conda/deactivate.d) works well enough, but it is inconvenient if you want the environment variables to be version controlled without putting the entire environment into version control too. Generally you'd want to store only the environment.yml file in version control.
(I understand that this does not apply to all projects - sometimes the entire reason for using environment variables is to prevent that particular configuration getting stored in version control.)
My preference (on Windows, but the same principle would apply on Linux) is to create a (version-controlled) activate.cmd file in the root of the project directory that sets the environemnt variable(s) and then calls conda's own activate.bat script.
Example (a per-project pylint configuration):
set PYLINTRC=%cd%\pylintrc
#activate.bat %cd%\env
Note that on Windows at least you have to set the environment variables before calling activate.bat because the call to activate.bat never returns to the calling batch file. You also have to name your own script something other than activate.bat to avoid recursion, which is why I chose the cmd extension (which is treated by Windows as a batch file in this context).
So for virtualenv on Ubuntu I did the below where my virtual environement names is my_env and my environmental variables I want to persist were VAR_A and VAR_B:
virtualenv my_env
vim my_env/bin/activate
This opens the file and you can append your env variables to the end of the file like the below:
# This is me env variables to persist
export VAR_A=/home/developer/my_workspace/var_a
export VAR_B=/home/developer/my_workspace/var_b
Then exit the file.
Activate your virtualenv with
source my_env/bin/activate
Then your env variables should be good. Can verify like the below:
printenv | grep VAR_
VAR_B=/home/developer/my_workspace/var_b
VAR_A=/home/developer/my_workspace/var_a
How I can EXPORT environment variable not just for one tab but for all system?
If i will use export JAVA_HOME=/Library/Java/Home it will set JAVA_HOME only for current terminal tab and after system restart I will need do it one more time.
How I can set environment variable globally to make by default?
How I can edit variables in $ env list?
Add an entry to ~/.bash_profile:
export JAVA_HOME=/Library/Java/Home
save it, (or create it if it doesn't exist)
quit Terminal.app
re-launch and you're in business.
This is the best place to add the entry in my opinion, although for the distinct differences on OS X of where to add environment variables specifically for one reason or another see:
https://apple.stackexchange.com/a/13019
And for a more generalized UNIX overview:
What's the difference between .bashrc, .bash_profile, and .environment?
You can set environment variables by adding the export commands to various configuration files. E.g. ~/.profile
You can find out more about what files can be used to modify your bash environment by reading the bash manual (man bash). If you're using a different shell then it's probably similar and its man page should contain the same info. You can also read this answer on unix.stackexchange.com, which has some of these details.
If you want to set environment variables for your entire user environment, including GUI applications, I believe you can do that using ~/.MacOSX/environment.plist.
I am installing Maven and need to set M2 and M2_Home. I have set them in the user variables in Environment variables. And I added ;%M2% to the Path variable in the System variables in Environment variables. I was expecting to be able to run mvn --version but I couldn't. However if I do
echo %Path% I can see that there is %M2% in the Path and if I echo %M2% I can see the bin directory that mvn is in.
So I had this problem. The problem did not get solved until I created a Path variable in user variables and added %M2% to that one (and removed it from the path in System variables). Now it works. Does any one know why it is only working in this specific way?
You'd have to look at the Windows source code to be certain what's going on, but this doesn't surprise me. Based on my testing, it appears that system environment variables can only reference other system environment variables, not user environment variables.
Note that echo %PATH% should show the expanded path. You shouldn't see %M2%.
This is probably because system environment variables sometimes need to be expanded in situations where there is no user context. If user environment variables were included in the expansion of system environment variables this would need to be treated as a special case. It's also possible that this was considered the preferred behaviour so that a user's environment variables couldn't unexpectedly affect the interpretation of system variables, or that there are issues related to the way environment variables are inherited between processes.
Either add %M2% to the user path as you've done, or make M2 a system rather than a user environment variable.
How can I always run Ruby scripts with warnings turned on by default, by modifying my Unix or Windows environment variables?
Ideally this should work even when I'm running a script indirectly such as through Rake, not just when I'm running it directly.
Based on a comment in this answer.
The RUBYOPT environment variable defines default options like warnings, etc.
Unix/OS X/etc:
export RUBYOPT=-w
You can put this in your startup script in Unix so it's set for new shells.
Windows:
set RUBYOPT=-w
Use the system properties dialog to set it for new shells/command windows.