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?
You also have an alias in functons.sh
with the same name as a function in your other file.
In functons.sh
:
alias zzz=sz
In z.sh
:
zzz () {
df -h
}
This confuses bash
.
Example:
$ cat f1
foo () { echo hello; }
alias xfoo=foo
$ cat f2
xfoo () { echo beep; }
$ source f1
$ source f2
$ shopt -s extdebug
$ declare -F foo
foo 1 f2
Without the xfoo
alias in f1
:
$ source f1
$ source f2
$ shopt -s extdebug
$ declare -F foo
foo 1 f1
The bash
manual also includes the text
Aliases are confusing in some uses.
under the "BUGS" heading.
Best Answer
Note: the statements here apply to Bash version 4.0.35 and up. Implementations of
set -e
vary wildly among different shells/versions. Follow Stéphane's advice and don't useset -e
.man bash
in the Shell Builtin Commands/set
section explains things pretty well though the text is a little dense and requires a bit of focus. To your specific questions the answers are:set -e
behave different here...vs.. - Depends on what you mean by "differently" but I suspect you'd consider the answer "no"...there are no tricky scoping rules. It acts quite linearlly.set -e
in a function and then encounter a non-zero status after return? Yes, this will exit.