← Back to Bash Course | Chapter 5: Functions | Lesson 11 of 11

Sourcing Files to Share Functions

The 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.

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

bash
#!/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)"

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

bash
#!/bin/bash
cat <<'EOF' > greetlib.sh
say_hello() {
    echo "Hello from the sourced library!"
}
EOF
. ./greetlib.sh
say_hello

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

bash
#!/bin/bash
cat <<'EOF' > config.sh
APP_NAME="MyTool"
VERSION="1.2.0"
EOF
source config.sh
echo "$APP_NAME version $VERSION"

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

bash
#!/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"
Common Mistakes
  1. Confusing source file.sh with bash file.sh or ./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.
  2. 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'.
  3. Sourcing a file that calls exit; since sourcing runs in the current shell, an exit inside the sourced file will terminate your *entire* current shell/script, not just return from the sourced file.
Chapter Summary
  • source filename and . filename are 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 source line 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 exit in the sourced file ends the whole calling script, not just the sourced portion.

Login to run this code

C/C++/Java/PHP execution requires a free account. Your code is saved — you'll land right back in the editor after logging in.