I've always used the term "environment variable", but I have a well-informed colleague who consistently says "environmental variable".
Which one is correct?
Environment Variable
While environmental variable is used occasionally, environment variable is overwhelmingly more common:
Wikipedia: Environment Variable
Arch Linux wiki: Environment variables
"environment var" => 28 instances
"environmental var" => 3 instances
POSIX.1‐2017, Chapter 8. Environment Variables
(title)
Linux man pages:
environ(7) -- "Environment variables may be..."
getenv(3) -- "get an environment variable"
execve(2) -- just "environment"
bash(1) -- mostly just "environment", but occasionally "environment variable" and never "environmental"
Linux kernel
git grep -i 'environment var' | wc -l => 183
git grep -i 'environmental var' | wc -l => 2
MSDN
getenv() -- "Environment variable name"
GetEnvironmentVariable()
Environment.GetEnvironmentVariable()
Python
os module
Perl
Env -- "Perl maintains environment variables..."
Google
Stack Overflow
An environment-variables tag exists, but environmental-variables does not
There are 90,719 results for "environment variable" but only 4,345 results for "environmental variable"
"Environment Variables" is the correct.
And as you have mentioned about MSDN, I would like to further add that on Windows Machine, the start search also shows "Edit the system environment variables" as follows:
Related
When I am trying to set environment variables using PowerShell in Windows Terminal with the command set test1=value1, I get no errors. However, when I try to check all environment variables using the set command, I get the following prompt:
cmdlet Set-Variable at command pipeline position 1
Supply values for the following parameters:
Name[0]:
I read that when using PowerShell you set environment vars using this:
$Env:test1 = "value1";
I want to set the variables so that on my backend in custom-environment-variables.json
I can store a name by which config can extract it using config.get("test").
custom-environment-variables.json:
{
"test": "test1",
}
But every time I try this, it says Error: Configuration property "test" is not defined.
Doing the same procedure CMD (either directly or through Windows Terminal) I get no issues whatsoever. Any ideas what might be causing this?
First, the easy part:
I get no errors but when I try to check all env. variables calling "set" I get the following prompt:
That's because the set command in PowerShell behaves differently. It's an alias for the PowerShell Set-Variable cmdlet. You can see this with Get-Alias.
Also, PowerShell variables are not environment variables. As you commented, the proper way to set an environment variable in PowerShell is with:
$env:variablename = "value"
The equivalent command to set (to get a list of all environment variables and their values) in PowerShell is:
Get-ChildItem env:
# Or using the alias
dir env:
# Or using another alias
ls env:
This access the PowerShell "environment provider", which is essentially (my grossly oversimplified summary) a "virtual drive/filesystem" that PowerShell provides which contains the environment variables. You can also create variables in here.
More reading: about_Environment_Variables from the PowerShell Doc.
As for the core issue with the config module, I haven't been able to reproduce that. It works correctly for me in both PowerShell and CMD. So let me run through my results in the hopes that it will help you see what might be different. All tests were performed in Windows Terminal, although as we've determined in the comments, this is more a difference in PowerShell vs. CMD for you:
config\default.json:
{
"test": "Original Value"
}
config\custom-environment-variables.json:
{
"test": "test1"
}
CMD without test1 variable set:
Running node in CMD:
> const config = require('config')
undefined
> config.get('test')
'Original Value'
>
CMD with test1 variable set:
Exit Node, and back in CMD:
>set test1=Override
>node
In Node:
Welcome to Node.js v14.16.1.
Type ".help" for more information.
> const config = require('config')
undefined
> config.get('test')
'Override'
>
PowerShell without test1 variable set:
Welcome to Node.js v14.16.1.
Type ".help" for more information.
> const config = require('config')
undefined
> config.get('test')
'Original Value'
>
PowerShell with test1 variable set:
In PowerShell:
PS1> $env:test1="Override"
PS1> node
In Node:
Welcome to Node.js v14.16.1.
Type ".help" for more information.
> const config = require('config')
undefined
> config.get('test')
'Override'
>
When I use any command with sudo the environment variables are not there. For example after setting HTTP_PROXY the command wget works fine without sudo. However if I type sudo wget it says it can't bypass the proxy setting.
First you need to export HTTP_PROXY. Second, you need to read man sudo, and look at the -E flag. This works:
$ export HTTP_PROXY=foof
$ sudo -E bash -c 'echo $HTTP_PROXY'
Here is the quote from the man page:
-E, --preserve-env
Indicates to the security policy that the user wishes to preserve their
existing environment variables. The security policy may return an error
if the user does not have permission to preserve the environment.
The trick is to add environment variables to sudoers file via sudo visudo command and add these lines:
Defaults env_keep += "ftp_proxy http_proxy https_proxy no_proxy"
taken from ArchLinux wiki.
For Ubuntu 14, you need to specify in separate lines as it returns the errors for multi-variable lines:
Defaults env_keep += "http_proxy"
Defaults env_keep += "https_proxy"
Defaults env_keep += "HTTP_PROXY"
Defaults env_keep += "HTTPS_PROXY"
For individual variables you want to make available on a one off basis you can make it part of the command.
sudo http_proxy=$http_proxy wget "http://stackoverflow.com"
You can also combine the two env_keep statements in Ahmed Aswani's answer into a single statement like this:
Defaults env_keep += "http_proxy https_proxy"
You should also consider specifying env_keep for only a single command like this:
Defaults!/bin/[your_command] env_keep += "http_proxy https_proxy"
A simple wrapper function (or in-line for loop)
I came up with a unique solution because:
sudo -E "$#" was leaking variables that was causing problems for my command
sudo VAR1="$VAR1" ... VAR42="$VAR42" "$#" was long and ugly in my case
demo.sh
#!/bin/bash
function sudo_exports(){
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) "$#"
}
# create a test script to call as sudo
echo 'echo Forty-Two is $VAR42' > sudo_test.sh
chmod +x sudo_test.sh
export VAR42="The Answer to the Ultimate Question of Life, The Universe, and Everything."
export _EXPORTS="_EXPORTS VAR1 VAR2 VAR3 VAR4 VAR5 VAR6 VAR7 VAR8 VAR9 VAR10 VAR11 VAR12 VAR13 VAR14 VAR15 VAR16 VAR17 VAR18 VAR19 VAR20 VAR21 VAR22 VAR23 VAR24 VAR25 VAR26 VAR27 VAR28 VAR29 VAR30 VAR31 VAR32 VAR33 VAR34 VAR35 VAR36 VAR37 VAR38 VAR39 VAR40 VAR41 VAR42"
# clean function style
sudo_exports ./sudo_test.sh
# or just use the content of the function
eval sudo $(for x in $_EXPORTS; do printf '%q=%q ' "$x" "${!x}"; done;) ./sudo_test.sh
Result
$ ./demo.sh
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
Forty-Two is The Answer to the Ultimate Question of Life, The Universe, and Everything.
How?
This is made possible by a feature of the bash builtin printf. The %q produces a shell quoted string. Unlike the parameter expansion in bash 4.4, this works in bash versions < 4.0
Add code snippets to /etc/sudoers.d
Don't know if this is available in all distros, but in Debian-based distros, there is a line at or near the tail of the /etc/sudoers file that includes the folder /etc/sudoers.d. Herein, one may add code "snippets" that modify sudo's configuration. Specifically, they allow control over all environment variables used in sudo.
As with /etc/sudoers, these "code snippets" should be edited using visudo. You can start by reading the README file, which is also a handy place for keeping any notes you care to make:
$ sudo visudo -f /etc/sudoers.d/README
# files for your snippets may be created/edited like so:
$ sudo visudo -f /etc/sudoers.d/20_mysnippets
Read the "Command Environment" section of 'man 5 sudoers'
Perhaps the most informative documentation on environment configuration in sudo is found in the Command environment section of man 5 sudoers. Here, we learn that a sudoers environment variables that are blocked by default may be "whitelisted" using the env_check or env_keep options; e.g.
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
Defaults env_keep += "ftp_proxy FTP_PROXY"
And so, in the OP's case, we may "pass" the sudoer's environment variables as follows:
$ sudo visudo -f /etc/sudoers.d/10_myenvwlist
# opens the default editor for entry of the following lines:
Defaults env_keep += "http_proxy HTTP_PROXY"
Defaults env_keep += "https_proxy HTTPS_PROXY"
# and any others deemed useful/necessary
# Save the file, close the editor, and you are done!
Get your bearings from '# sudo -V'
The OP presumably discovered the missing environment variable in sudo by trial-and-error. However, it is possible to be proactive: A listing of all environment variables, and their allowed or denied status is available (and unique to each host) from the root prompt as follows:
# sudo -V
...
Environment variables to check for safety:
...
Environment variables to remove:
...
Environment variables to preserve:
...
Note that once an environment variable is "whitelisted" as above, it will appear in subsequent listings of sudo -V under the "preserve" listing.
If you have the need to keep the environment variables in a script you can put your command in a here document like this. Especially if you have lots of variables to set things look tidy this way.
# prepare a script e.g. for running maven
runmaven=/tmp/runmaven$$
# create the script with a here document
cat << EOF > $runmaven
#!/bin/bash
# run the maven clean with environment variables set
export ANT_HOME=/usr/share/ant
export MAKEFLAGS=-j4
mvn clean install
EOF
# make the script executable
chmod +x $runmaven
# run it
sudo $runmaven
# remove it or comment out to keep
rm $runmaven
I am trying to use the "az pipelines variable-group variable create ..." command to create a variable which references a different variable. e.g.
az pipelines variable-group variable create --project MyTestProject --
group-id 15 --name ‘ApplicationName’ --value 'TestApp-$(env)'
where the variable “env” is defined in a variable-group within the same project library.
When I run the command above it gives the error:
“Failed to load python executable” “exit /b 1”.
Despite an error being generated the variable is created; in the example above the variable 'ApplicationName' has the value 'TestApp-$(env', the trailing bracket character, ")", is missing and seems to be causing the problem.
The dollar sign, "$", and/or the opening bracket character "(" don't generate any error when used without the closing bracket ")".
I have tried escaping the closing bracket character with backslashes "\" and caret "`" characters but couldn't find any combination that would create the desired variable value, "TestApp-$(env)".
Could someone tell me how to escape the closing bracket so the variable is correctly created within the variable group.
I am running the following versions of az:
azure-cli 2.0.73
command-modules-nspkg 2.0.3
core 2.0.73
nspkg 3.0.4
telemetry 1.0.3
Extensions:
azure-devops 0.12.0
Python (Windows) 3.6.6
Many Thanks,
Gary
I have finally managed to figure out how to escape a variable whose name itself contains a different variable name. By calling the az cli command and wrapping the variable value in double quotes and a single quote, the variable is correctly created in DevOps:
pipelines variable-group variable create --project MyTestProject -- group-id 15 --name ApplicationName' --value '"TestApp-$(env)"'
DevOps-LibraryVariable-screenshot
As a further expansion on this topic I had a need to pass the value as a variable. My source was in a key value pair. In this case I used the following.
$key = $var.Key
$value = '"{0}"' -f $var.Value
az pipelines variable-group variable update --group-id $groupId --org $org --project $project `
--name $key --value $value
It depends on your OS and tools.
For example, in Windows OS, you can get environment variable with %variable_name%. So, the following would be right:
az pipelines variable-group variable create --project keyvault --group-id 1 --name "ApplicationName" --value "TestApp-%java_home%"
However, in PowerShell, you can get environment with "$env:variable_name". So, the following would be right:
az pipelines variable-group variable create --project keyvault --group-id 1 --name "ApplicationName2" --value "TestApp-$($env:java_home)"
Update:
So, in Azure Pipeline, you can use group variables as following:
pool:
name: Hosted VS2017
demands:
- msbuild
- visualstudio
- vstest
variables:
- group: vargroup
steps:
- task: AzureCLI#1
inputs:
azureSubscription: 'CSP Azure (e5b0fcfa-e859-43f3-8d84-5e5fe29f4c68)'
scriptLocation: 'inlineScript'
inlineScript: |
echo the variable var1:%var1%
I have a variable group:
And you can see that: echo the variable var1:%var1% will be echo the variable var1:value1
When I execute the printenv command on the go-agent
go#05f749b73185:/tmp$ printenv
HOSTNAME=05f749b73185
SHELL=/bin/bash
USER=go
LS_COLORS=
MAVEN_VERSION=3.3.9
MAIL=/var/mail/go
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
MAVEN_HOME=/usr/share/maven
PWD=/tmp
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/
LANG=en_US.UTF-8
HOME=/var/go
SHLVL=2
LOGNAME=go
LC_CTYPE=en_US.UTF-8
LESSOPEN=| /usr/bin/lesspipe %s
LESSCLOSE=/usr/bin/lesspipe %s %s
_=/usr/bin/printenv
But when I execute the printenv command from inside a job i get this result
06:57:26.482 [go] Start to execute task: <exec command="printenv" />.
06:57:26.493 GO_SERVER_URL=https://go-server:8154/go/
06:57:26.493 JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre
06:57:26.494 SHLVL=2
06:57:26.494 MAVEN_HOME=/usr/share/maven
06:57:26.495 LOG_DIR=/var/log/go-agent
06:57:26.495 GO_TRIGGER_USER=anonymous
06:57:26.495 GO_SERVER=go-server
06:57:26.496 GO_PIPELINE_LABEL=8
06:57:26.496 GO_STAGE_NAME=build
06:57:26.497 HOSTNAME=05f749b73185
06:57:26.497 PWD=/var/lib/go-agent
06:57:26.498 GO_STAGE_COUNTER=1
06:57:26.498 AGENT_WORK_DIR=/var/lib/go-agent
06:57:26.499 GO_JOB_NAME=Compile
06:57:26.499 MAVEN_VERSION=3.3.9
06:57:26.499 OLDPWD=/etc/service/go-agent
06:57:26.500 LC_CTYPE=en_US.UTF-8
06:57:26.500 AGENT_STARTUP_ARGS=-Dcruise.console.publish.interval=10 -Xms128m -Xmx256m -Djava.security.egd=file:/dev/./urandom
06:57:26.501 GO_FROM_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.501 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
06:57:26.501 GO_TO_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.502 USER=go
06:57:26.502 GO_SERVER_PORT=8153
06:57:26.502 GO_PIPELINE_NAME=DropwizardSeed
06:57:26.503 HOME=/var/go
06:57:26.503 UID=103
06:57:26.503 GO_ENVIRONMENT_NAME=local
06:57:26.506 INITRD=no
06:57:26.507 GO_PIPELINE_COUNTER=8
06:57:26.508 GO_REVISION=b6f8f0f3bedabe1cc0ffa1334c290f32da723cde
06:57:26.509 LANG=en_US.UTF-8
If you look at the JAVA_HOME environment variable it's different between the job call and the call directly when you're logged in the machine.
This can be solved by setting the environment variable in the pipeline, but how can I configure my go-server and go-agents so I don't have to do this? What if I want to use another JDK as default?
Where does that JAVA_HOME environment variable come from?
Have you checked /etc/default/<agent-name>
In this file you can define the default values for an agent and you can also define environment variables using export command.
I have used "rebar generate" to create the package and move package to the test pc for running.
But when running the common test suite, I don't know how to "-env ERL_LIBS XXX" with "ct_run" command.
How to correct it?
ct_run -dir /home/peter/gate-0.0.1.20/lib/gate-0.0.1.20/ct -suite gate_test_data_SUITE.erl -erl_args -- -env ERL_LIBS gate-0.0.1.20/lib
This variable also works for the environment. Have you tried running the command as ERL_LIBS gate-0.0.1.20/lib ct_run -dir /home/peter/gate-0.0.1.20/lib/gate-0.0.1.20/ct -suite gate_test_data_SUITE.erl ?