Sourcing Files to Share Functions
source command (or its shorthand .) runs another script's commands directly inside your current shell, which is how you share functions and variables between multiple script files.In this page:
Sourcing a File to Import Functions
source filename (or the equivalent shorthand . filename) executes another file's commands directly within the current shell, so any functions or variables it defines become available afterward in the calling script. This is the standard mechanism for splitting shared logic into a reusable library file.
Example: Sourcing a File to Import Functions
#!/bin/bash
cat <<'EOF' > mathlib.sh
add() {
echo $(( $1 + $2 ))
}
multiply() {
echo $(( $1 * $2 ))
}
EOF
source mathlib.sh
echo "3 + 4 = $(add 3 4)"
echo "3 * 4 = $(multiply 3 4)"
Login to try C/C++/Java/PHP code in the editor
The . Shorthand
The single dot . is a POSIX-standard shorthand for source and behaves identically; . ./mathlib.sh is exactly equivalent to source ./mathlib.sh. The dot form is more portable to shells other than Bash, while source is more explicit and readable.
Example: The . Shorthand
#!/bin/bash
cat <<'EOF' > greetlib.sh
say_hello() {
echo "Hello from the sourced library!"
}
EOF
. ./greetlib.sh
say_hello
Login to try C/C++/Java/PHP code in the editor
Variables Are Shared Too
Sourcing shares not just functions but also plain variables defined in the sourced file, since the file's contents run directly in the current shell's own environment. This makes sourcing useful for sharing configuration values as well as reusable functions.
Example: Variables Are Shared Too
#!/bin/bash
cat <<'EOF' > config.sh
APP_NAME="MyTool"
VERSION="1.2.0"
EOF
source config.sh
echo "$APP_NAME version $VERSION"
Login to try C/C++/Java/PHP code in the editor
Sourcing Runs in the Current Shell, Not a Subshell
Unlike bash script.sh or ./script.sh (which start a brand-new child shell that exits independently), source script.sh executes entirely within the calling shell. This is why an exit command inside a sourced file terminates the whole calling script rather than just returning control to it.
Warning: Avoid putting a bare exit in a file meant to be sourced -- use return instead so it only stops the sourced file's own execution, not the whole calling shell.
Example: Sourcing Runs in the Current Shell, Not a Subshell
#!/bin/bash
cat <<'EOF' > safe_lib.sh
lib_function() {
echo "Library function ran without exiting the caller"
}
EOF
source safe_lib.sh
lib_function
echo "Caller script continues normally after sourcing"
Login to try C/C++/Java/PHP code in the editor
- Confusing
source file.shwithbash file.shor./file.sh; sourcing runs the file's commands in the *current* shell (so functions/variables it defines remain available afterward), while executing it normally runs it in a brand-new child shell that exits when the script ends, taking its definitions with it. - Forgetting that a sourced file needs a correct relative or absolute path; if the file isn't in the current directory and isn't found via
PATH, sourcing fails with 'No such file or directory'. - Sourcing a file that calls
exit; since sourcing runs in the current shell, anexitinside the sourced file will terminate your *entire* current shell/script, not just return from the sourced file.
source filenameand. filenameare equivalent; both run the file's contents in the current shell rather than a subshell.- Functions and variables defined in a sourced file remain available in the sourcing script after the
sourceline completes. - This is the standard way to build a shared library of functions used across multiple scripts, e.g.
source ./lib/helpers.sh. - Because sourcing shares the current shell, an
exitin the sourced file ends the whole calling script, not just the sourced portion.
Chapter Quiz — Complete all 11 topics to unlock
0/11 topics done
Complete these topics first: