Bash source Command: Source vs Execute a Script

Use source (or .) when a file should change the shell you are typing in. Run bash file or ./file when you want a separate process that cannot leave variables, functions, or cd changes behind.

That distinction matters for shared libraries, environment snippets, and one-off setup scripts. The sections below run the same helper file four ways and print what survived in the current shell afterward.

source vs Execute — Quick Decision Table

source evaluates commands in the current shell execution environment. bash file and ./file start a new process (a child of your shell). ( commands ) is Bash's explicit subshell compound command — different from "every script is a subshell."

Pipelines such as cmd | while read run the loop in a subshell in Bash's default model — that is a pipeline rule, not the same thing as ./script.sh. See read a file line by line for the pipe-versus-redirection distinction.

source and . make the current shell read the file, so the file does not need execute permission and its shebang does not choose the interpreter. bash script.sh explicitly chooses Bash, so it also does not require the executable bit. With ./script.sh, the operating system executes the file, so execute permission and a suitable shebang normally matter.

What source Does

The source builtin reads a file and runs each command as if you had typed it in the current shell. Assignments, function definitions, cd, set options, and trap handlers can all persist after the file finishes.

The exit status of source is the status of the last command executed from that file. If the file cannot be read, source fails.

source and . Syntax

In Bash these forms are equivalent:

source ./library.sh

The POSIX dot form runs the same builtin:

. ./library.sh

POSIX specifies the . command. In Bash, source is a builtin synonym for . — not a shell alias. Prefer ./filename when the file is in the current directory; bare names follow the lookup rules in the section below.

Run the Same File Four Ways

Work in a dedicated directory so PWD in the samples stays predictable:

mkdir -p /tmp/source-demo

Run the rest of the comparisons from that directory:

cd /tmp/source-demo

Create a small library file that sets a variable, defines a function, and changes directory:

cat > library.sh <<'EOF'
#!/usr/bin/env bash
LIB_VAR="from_library"
lib_fn() { printf 'lib_fn:%s\n' "$1"; }
cd /tmp
EOF

Make the library executable so ./library.sh can run as a separate program — only direct exec needs the execute bit; see Linux file permissions for chmod +x:

chmod +x library.sh

Add a helper that prints what the current shell still sees:

show_state() {
  printf 'LIB_VAR=%s\n' "${LIB_VAR-unset}"
  if declare -F lib_fn >/dev/null 2>&1; then
    printf 'lib_fn=defined\n'
  else
    printf 'lib_fn=unset\n'
  fi
  printf 'PWD=%s\n' "$PWD"
}

Run the file as an executable in a child process:

./library.sh

Inspect what the current shell still sees after the child process exits:

show_state

LIB_VAR=unset
lib_fn=unset
PWD=/tmp/source-demo

Only the child entered /tmp; your interactive shell stayed in /tmp/source-demo.

Start a new Bash process explicitly:

bash library.sh

The parent shell should look the same as after ./library.sh:

show_state

LIB_VAR=unset
lib_fn=unset
PWD=/tmp/source-demo

Same outcome: the child process discarded the assignments, function, and cd.

Load the file into the current shell with source:

source ./library.sh

Sourcing runs cd /tmp in the current shell, so show_state should report the loaded variable and function:

show_state

LIB_VAR=from_library
lib_fn=defined
PWD=/tmp

The dot command produces the same result:

Reset with cd /tmp/source-demo, then load again with the dot command:

cd /tmp/source-demo

Load the library with the dot builtin:

. ./library.sh

The dot form should match source line for line:

show_state

LIB_VAR=from_library
lib_fn=defined
PWD=/tmp

Only sourcing changed the session you are in. Executing the file as a program did not.

What Persists in the Current Shell?

After source, these commonly persist:

• Variables — ordinary assignments and export names; see Bash variables for scope and export rules
• Functions — definitions from Bash functions using name() { ... } or function name { ... }
• Working directory — cd inside the sourced file
• Shell options and traps — set -e, set -o pipefail, shopt, and trap affect the current shell until you change them again

A child script process cannot leave those behind when it exits.

Reload .bashrc in the current shell

Many guides tell you to run:

source ~/.bashrc

Equivalent Bash form:

. ~/.bashrc

This applies changes from .bashrc to the terminal you are already using — bashrc vs bash profile explains when that file runs versus .bash_profile. Running bash ~/.bashrc would start another Bash process instead, so environment changes made there would not remain in the current shell after that process exits.

Pass Arguments to a Sourced File

When you pass arguments to source, Bash uses them as the sourced file's positional parameters for that invocation, then restores the caller's positional parameters when the sourced file returns.

Create a short file:

cat > greet.sh <<'EOF'
printf 'Inside greet: $1=%s $2=%s $#=%s\n' "$1" "$2" "$#"
EOF

Set a marker in the parent shell and source with two arguments:

set -- keep_me

Print the parent positional parameters before sourcing:

printf 'Before: $1=%s $#=%s\n' "$1" "$#"

Pass Alice and Bob as temporary positional parameters to the sourced file:

source ./greet.sh Alice Bob

Before: $1=keep_me $#=1
Inside greet: $1=Alice $2=Bob $#=2

Check that the parent parameters returned:

printf 'After: $1=%s $#=%s\n' "$1" "$#"

After: $1=keep_me $#=1

The same rules apply to . ./greet.sh Alice Bob. See Bash script arguments for positional parameters in executed scripts.

Exit Status and return in Sourced Files

The status of source matches the last command in the file:

cat > status.sh <<'EOF'
false
true
EOF

The last command in the file is true, so source should succeed:

source ./status.sh

Read the status immediately — it reflects the last command in status.sh:

printf 'exit=%s\n' "$?"

exit=0

return inside a sourced file exits the source call with that status (it does not exit your interactive shell):

cat > ret.sh <<'EOF'
return 42
EOF

return at the top level of a sourced file sets the status of the source call:

source ./ret.sh

The return value becomes the exit status of source:

printf 'exit=%s\n' "$?"

exit=42

return outside a function is only valid while a file is being sourced (or inside a function). In an executed script, top-level return is an error. See Bash exit codes for how $? fits the wider model.

Source a Function Library

Put reusable functions in lib.sh and guard top-level side effects with Bash [ ] vs [[ ]] vs (( )) so the file is safe to source:

cat > lib.sh <<'EOF'
my_util() { printf 'util\n'; }

if [[ ${BASH_SOURCE[0]} == "$0" ]]; then
  printf 'main block ran\n'
fi
EOF

Sourcing loads the function and skips the standalone block:

source ./lib.sh

Call the function that the library defined:

my_util

util

Executing the same file runs the main block because BASH_SOURCE[0] and $0 match in that process:

bash lib.sh

main block ran

When the file is sourced, BASH_SOURCE[0] and $0 differ, so only the function definition is loaded. When the file is executed with bash lib.sh, they match and the standalone block runs. In a real program, the usual pattern is if [[ ${BASH_SOURCE[0]} == "$0" ]]; then main "$@"; fi.

How Bash Finds a Sourced File

Bash resolves the filename before it runs any commands from the file. The rules depend on whether the name contains / and on the sourcepath shell option (shopt -s sourcepath, on by default).

A bare name such as demo.sh is not the same as ./demo.sh. With sourcepath enabled, Bash may load a different demo.sh from PATH before it ever looks in the current directory. Prefer ./demo.sh or an absolute path in scripts you ship.

Demonstrate PATH lookup from /tmp/source-demo:

cd /tmp/source-demo

Create a helper script outside the current directory name:

mkdir -p bin

Write a one-line script that only sets DEMO:

cat > bin/demo.sh <<'EOF'
DEMO=from_path
EOF

Put bin on PATH and allow source to search it:

export PATH="$PWD/bin:$PATH"

Enable sourcepath so bare filenames search PATH:

shopt -s sourcepath

Clear any old value, then source by bare filename:

unset DEMO

Bash should find demo.sh under $PWD/bin through PATH:

source demo.sh

Confirm the assignment reached the current shell:

printf 'DEMO=%s\n' "${DEMO-unset}"

DEMO=from_path

Put a different demo.sh in the current directory so you can tell PATH lookup apart from the working-directory fallback:

printf 'DEMO=from_cwd\n' > demo.sh

Turn sourcepath off so bare names no longer search PATH:

shopt -u sourcepath

Clear the earlier value before sourcing again:

unset DEMO

Bash should load ./demo.sh from the current directory, not bin/demo.sh from PATH:

source demo.sh

Confirm the cwd file won:

printf 'DEMO=%s\n' "${DEMO-unset}"

DEMO=from_cwd

With sourcepath disabled, PATH is not searched. A bare filename is resolved only in the current directory.

Bash 5.3+: source -p path

Bash 5.3 added a -p path option to source and .:

source -p path filename [arguments]

Here path is a colon-separated directory list Bash uses to find filename. It replaces the usual PATH search for that one source call. Bash searches only the directories supplied with -p; it does not fall back to the current directory if the file is not found there. It does not change the shell's PATH variable, and commands inside the sourced file still use the existing PATH when they run external programs.

Prepare a library outside any PATH directory:

mkdir -p /tmp/source-lib

Write a one-line library file there:

printf 'DEMO=from_custom_path\n' > /tmp/source-lib/demo.sh

On Bash 5.3+, load it by search path instead of by full pathname:

source -p /tmp/source-lib demo.sh

Read the variable the sourced file set:

printf 'DEMO=%s\n' "$DEMO"

DEMO=from_custom_path

-p /tmp/source-lib tells Bash to look in /tmp/source-lib for demo.sh instead of searching $PATH. Your interactive PATH is unchanged.

Check the version before relying on -p:

if (( BASH_VERSINFO[0] > 5 || (BASH_VERSINFO[0] == 5 && BASH_VERSINFO[1] >= 3) )); then
  printf 'source -p is available\n'
else
  printf 'source -p needs Bash 5.3+\n'
fi

source -p needs Bash 5.3+

On Bash 5.2 (including the lab package bash 5.2.26-6.el10), -p is rejected:

source -p /tmp/source-lib demo.sh

bash: source: -p: invalid option
source: usage: source filename [arguments]

Use an explicit path such as source /tmp/source-lib/demo.sh on older Bash, or gate on BASH_VERSINFO before calling source -p.

Why Sourcing “Config Files” Can Be Dangerous

source does not parse a file — it executes it as shell code. A file named app.conf can run rm, redefine functions, or exfiltrate data if you source it blindly.

Treat source like running a script in your current shell with your credentials and environment.

Common Problems

Summary

The Bash source command (and the dot builtin) evaluate a file in the current shell, so variables, functions, cd, and shell options can persist after the file returns. Running bash file or ./file starts a separate process whose changes disappear when that process exits — that is not the same as Bash's ( subshell ) syntax, which is an explicit compound command for isolation.

Use source ./lib.sh when you deliberately want to load a library into the session you are using. Pass arguments after the filename; Bash restores your previous positional parameters when sourcing finishes. Check $? after source for the last command's status, and use return N inside sourced files to exit the load with a chosen code.

Prefer explicit paths for files you ship, understand how sourcepath and bare filenames interact with PATH and the current directory, and never source untrusted files just to read configuration data. On Bash 5.3+, source -p path file searches path for file without changing your shell PATH; on Bash 5.2, use a full pathname or upgrade before relying on -p.

References

• GNU Bash Manual — Bourne Shell Builtins — source
• GNU Bash Manual — Bourne Shell Builtins — .
• POSIX Shell Command Language — dot
• Bash 5.3 release notes — source -p path