Environment Variables
CommandBox allows you to access Java System Properties from the CLI and environment variables from your operating system via the
${name_here} mechanism. But CommandBox also gives you the ability to create variables of your own directly in the shell. The scope (life) of these environment variables depends on how and where they are declared.Shell Environment Variables (Global)
Every shell instance has its own set of environment variables you can set and read. These live for the duration of the shell and have the same lifespan as Java system properties in the CLI. There is an
env namespace of commands for dealing with environment variables.To set a new variable, you can run this:
1
env set foo=bar
2
​
3
# or just
4
set foo=bar
Copied!
You can view the contents of that variable from anywhere in the same shell session like so:
1
env show foo
2
​
3
# or provide a default value
4
env show foo myDefault
5
​
6
# Or via System Setting expansions
7
echo ${foo:myDefault}
Copied!
Clear out an environment variable like so:
1
env clear foo
Copied!
Per-Command Environment Variables
In addition to the global shell environment, each executing command receives its own set of environment variables that go away when the command finishes executing. Unlike Bash, the parent variables are not copied into each command, but a hierarchy is maintained and when a variable is not found, the parent command is checked and so on until the global shell variables. After that, the Java system properties and then OS's actual environment is checked.
Here is a contrived example of an
echo command that run a sub command as part of a command expression (backtick expansion). The sub command sets an environment variable and then outputs it.1
echo `set myVar=cheese && echo \${myVar}`
2
env show myVar myDefault
Copied!
The first line will output the text "Cheese" but the second line will output the default value of "myDefaul" since the variable only existed in the inner context of the expression and isn't visible to the outer shell.
Recipes
Recipes behave like a subshell and any variables set in a recipe will live for the duration of that recipe but will be gone once the recipe exits.
Viewing Variables
To view the environment variable for the current command context, run:
1
> env set color=red
2
> env set number=2
3
> env show
4
{
5
"number":"2",
6
"color":"red"
7
}
Copied!
The output is a JSON serialized struct, which makes it suitable for programmatically accessing.
1
> env show | foreach "echo 'The var \${item} is set to \${value}'"
2
The var number is set to 2
3
The var color is set to red
Copied!
There is a command to help you debug what variables are set in each command context as well as the global shell. Here we pipe some commands into a recipe for execution. The context for the
env debug command has no variables, the recipe command has a variable called inRecipe and the global shell as the 2 variables from the example above.1
> echo "set inrecipe=true; env debug" | recipe
2
[
3
{
4
"environment":{},
5
"context":"env debug"
6
},
7
{
8
"environment":{
9
"inRecipe":"true"
10
},
11
"context":"recipe"
12
},
13
{
14
"environment":{
15
"number":"2",
16
"color":"red"
17
},
18
"context":"Global Shell"
19
}
20
]
Copied!
Native Binaries
Any environment variables you set in the CommandBox shell will be available to the native process that your OS binary runs in. Here's a Windows and *nix example of setting an env var in CommandBox and then using it from the native shell.
1
set name=brad
2
!echo %name%
Copied!
1
set name=brad
2
!echo $name
Copied!
Passing Environment Variables to Servers
Any ComandBox environment variables present in the shell will automatically be passed to the environment of the server process. This means, given an example like this:
1
set foo=bar
2
server start
Copied!
The CFML code running that server process will be able to "see" the
foo environment variable.Last modified 1mo ago