Exporting a variable from inside a function equals to global export of that variable?
Your script creates an environment variable, myVar
, in the environment of the script. The script, as it is currently presented, is functionally exactly equivalent to
#!/bin/bash
export myVar="myVal"
The fact that the export
happens in the function body is not relevant to the scope of the environment variable (in this case). It will start to exist as soon as the function is called.
The variable will be available in the script's environment and in the environment of any other process started from the script after the function call.
The variable will not exist in the parent process' environment (the interactive shell that you run the script from), unless the script is sourced (with .
or source
) in which case the whole script will be executing in the interactive shell's environment (which is the purpose of "sourcing" a shell file).
Without the function call itself:
myFunc() {
export myVar="myVal"
}
Sourcing this file would place myFunc
in the environment of the calling shell. Calling the function would then create the environment variable.
See also the question What scopes can shell variables have?
Related videos on Youtube
user9303970
Updated on September 18, 2022Comments
-
user9303970 over 1 year
I use Ubuntu 16.04 with the native Bash on it.
I'm not sure if executing
#!/bin/bash myFunc() { export myVar="myVal" } myFunc
equals in any sense, to just executing
export myVar="myVal"
.Of course, a global variable should usually be declared outside of a function (a matter of convention I assume, even if technically possible) but I do wonder about the more exotic cases where one writes some very general function and wants a variable inside it to still be available to everything, anywhere.
Would
export
of a variable inside a function, be identical to exporting it globally, directly in the CLI, making it available to everything in the shell (all subshells, and functions inside them)? -
Noam Manos over 3 yearsNote regarding subshells - If the function with the
export myvar
is called inside a ( subshell ), then the variable will still be unavailable in the parent scope. -
User Rebo over 3 yearsWhat didn't work for me if i wrapped the
export
in(set -x export MY_VAR=...)
-
Kusalananda over 3 years@UserRebo It's unclear what you want to do. The exported variable will only be visible inside the subshell, and when the subshell terminates it will be gone. This is usually the effect one wants with an explicit subshell like this. Likewise, the effect of the
set -x
will also be limited the subshell. -
User Rebo over 3 yearsOnly wanted to make a note for other users. The
set -x
will prevent exporting variables in any scope. Didn't really refer to the subshell. -
Kusalananda over 3 years@UserRebo
set -x
will absolutely not prevent exporting variables! It turns on tracing in the shell (i.e. the shell will produce debug output). It's the subshell that prevents the variable from being visible outside of the subshell. -
User Rebo over 3 yearsI wrote a minimal script and variable didn't work when i added the
set -x
or added braces:export MYVAR=\first
set -x export MYVAR=\second
(export MYVAR=\third)
echo "MYVAR: $MYVAR"
-
Kusalananda over 3 years@UserRebo Ah, now I see! You need
;
(or a newline) betweenset -x
andexport
. They are two separate commands. What you wrote originally,set -x export var=value
would set$1
to the stringexport
, and$2
to the stringvariable=value
. I didn't spot the missing;
as it was such an odd command to give. -
User Rebo over 3 years@NoamManos Nice thank you!