source / . (Dot)

Load another script in the current shell (source command).

source file_path

The dot (.) command does the same thing (POSIX-compliant).

. file_path

Reload a config file (apply changes immediately).

source ~/.bashrc
. ~/.bashrc

Load a function library.

source ./lib/functions.sh

Prepare the following two files. The file lib/config.sh defines shared settings.

sample_lib/config.sh

#!/usr/bin/env bash
DB_HOST="localhost"
DB_NAME="myapp"
DB_USER="dbuser"
APP_ENV="production"

log() {
    echo "[$(date +%Y-%m-%d\ %H:%M:%S)] $*"
}

Loading the config file with source makes its variables and functions available in the current shell.

sample_main.sh

#!/usr/bin/env bash
source ./lib/config.sh

log "Connecting to database: $DB_HOST/$DB_NAME"
echo "Environment: $APP_ENV"

bash main.sh
[2026-03-06 12:00:00] Connecting to database: localhost/myapp
Environment: production

Here is a pattern for loading a .env file to set environment variables all at once.

.env

API_KEY=secret123
DEBUG=true

sample_load_env.sh

source .env
echo "API key: $API_KEY"

bash load_env.sh
API key: secret123

This example shows the difference between source and bash. Because bash runs in a subshell, variables defined inside it do not carry over to the calling shell.

sample_diff_test.sh

cat > /tmp/test.sh <<'EOF'
MY_VAR="hello from script"
EOF

bash /tmp/test.sh
echo "After bash: ${MY_VAR:-undefined}"

bash diff_test.sh
After bash: undefined

When you load the file with source, it runs in the current shell, so the variable is inherited.

source /tmp/test.sh
echo "After source: $MY_VAR"
After source: hello from script

Common Mistake 1: Using bash instead of source — variables do not carry over

Running a script with bash creates a subshell, so variables defined inside it are not available in the calling shell. Use source when you want the variables to persist.

sample_wrong_bash.sh

bash ./lib/config.sh
echo "$DB_HOST"

bash wrong_bash.sh

（$DB_HOST is empty — bash ran in a subshell）

Use source to load the file in the current shell.

source ./lib/config.sh
echo "$DB_HOST"
localhost

Common Mistake 2: Errors in the sourced file can affect the current shell

Because source runs in the current shell, any errors or unexpected variable changes in the loaded file directly affect the calling shell's environment. Always check for errors after sourcing an untrusted file.

sample_safe_source.sh

if ! source ./lib/config.sh; then
    echo "Failed to load config. Aborting." >&2
    exit 1
fi
echo "Config loaded: $DB_HOST"

bash safe_source.sh
Config loaded: localhost

The key characteristic of source is that it runs in the current shell process. When you want changes to ~/.bashrc or ~/.zshrc to take effect immediately, use source ~/.bashrc.

Loading a "library file" that defines shared functions and variables with source is a common pattern for improving the maintainability of multiple scripts. If the target file does not exist, the command will fail, so it is safer to check for its existence first with [ -f file ] before loading.

[ -f config.sh ] && source config.sh

For details on conditional expressions, see test / [ ] / [[ ]].