source Command in Linux: Usage and Examples

Shell setup files only change your current terminal when the shell reads them in the current process. The source command in Linux is the Bash-friendly way to load variables, aliases, functions, and setup files without starting a child shell that immediately loses those changes.

Use source when the current shell must keep the result. Use a normal script run when the changes should stay isolated. For portable /bin/sh scripts, use the POSIX dot command (.) instead of source, because shells such as dash do not provide a source builtin.

Understand the source Command

source is a shell builtin, not a standalone Linux binary. In Bash, it reads a file and runs each command inside the current shell session. That behavior is why sourced variables, aliases, shell options, and functions remain available after the file finishes.

type source

Bash reports the builtin directly:

source is a shell builtin

The basic Bash syntax accepts a file name and optional arguments:

source filename [arguments]

The portable dot form reads the file in the current shell too:

. filename

Use an explicit path such as ./settings.sh when the file is in the current directory. Bare names can involve shell-specific path lookup, while ./ tells the shell exactly which file to read.

Compare source with running a script

Create a small demo file that sets one variable:

mkdir -p ~/source-demo && cd ~/source-demo && printf 'DEMO_MODE=enabled\n' > ./demo-settings.sh

The remaining examples assume ~/source-demo is still your current directory. The cleanup section removes this article-owned directory when the examples are finished.

Running that file in a child Bash process does not set the variable in your current terminal, but sourcing it does:

bash ./demo-settings.sh
printf 'after direct run: %s\n' "${DEMO_MODE:-unset}"

source ./demo-settings.sh
printf 'after source: %s\n' "$DEMO_MODE"

after direct run: unset
after source: enabled

The direct run changes only the child process. The sourced run changes the shell you are already using, so later commands in the same terminal can read $DEMO_MODE.

Use dot syntax in POSIX sh scripts

When a script runs under sh, the dot command is the portable current-shell form:

. ./demo-settings.sh
printf '%s\n' "$DEMO_MODE"

enabled

If sh points to dash or another minimal POSIX shell, source ./demo-settings.sh fails because source is not part of POSIX sh.

Load Variables and Functions with source

Sourcing works best for files that intentionally prepare the current shell: project environment files, aliases, functions, completion scripts, and shell startup files. Only source files you trust, because every command inside the file runs with your current shell privileges.

Load environment variables

Create a simple environment file:

cat <<'EOF' > ./app-env.sh
export APP_ENV=development
export APP_PORT=8080
EOF

Source the file, then print the variables from the same shell:

source ./app-env.sh
printf '%s\n' "$APP_ENV"
printf '%s\n' "$APP_PORT"

development
8080

Environment files can contain secrets, but sourcing them is not a security boundary. Keep sensitive files readable only by the account that needs them, and export a variable only when child processes must inherit it. For permission changes, use chmod command examples as a reference before changing access on shared files.

Reload a shell startup file

If you intentionally edited ~/.bashrc, source that exact file from an existing Bash session to apply new aliases, functions, or prompt settings without opening another terminal:

source ~/.bashrc

Reload only files written for the shell you are using. If a tool or installer created a narrower file, source that file instead of the whole startup file. A Bash-specific file such as ~/.bashrc can contain syntax that fails in sh, dash, or other shells.

Load shell functions

Sourcing is useful while testing helper functions because the function stays defined after the file finishes:

cat <<'EOF' > ./helpers.sh
greet() {
    printf 'Hello, %s!\n' "$1"
}
EOF

source ./helpers.sh
greet "Alice"

Hello, Alice!

Load aliases in the current shell

Aliases expand in interactive shells, so they usually belong in startup files or files sourced by an interactive shell:

cat <<'EOF' > ./aliases.sh
alias ll='ls -lah'
EOF

source ./aliases.sh
alias ll

alias ll='ls -lah'

Pass Arguments to source in Bash

Bash lets you pass temporary positional parameters to a sourced file. Those arguments become $1, $2, and $@ while the file runs, then the caller’s original positional parameters return afterward.

cat <<'EOF' > ./print-args.sh
printf 'inside: %s\n' "$*"
EOF

set -- original
source ./print-args.sh alpha beta
printf 'after: %s\n' "$*"

inside: alpha beta
after: original

Do not rely on argument passing with dot syntax in portable sh scripts. If a file must run under /bin/sh, keep the interface simple: set variables before the dot command, read variables inside the file, and avoid Bash-only syntax.

Use source Safely in Scripts

A sourced file runs in the caller’s shell, so mistakes can overwrite variables, redefine functions, change options, or run commands immediately. Add basic checks before sourcing optional or generated paths.

Source a file only when it is readable

Check the file before reading it. For a deeper look at test operators, see how to check whether a file or directory exists in Bash.

if [ -r ./optional-config.sh ]; then
    source ./optional-config.sh
fi

Use -r when the next operation is reading the file. Use -f only when the important condition is that the path is a regular file.

Quote generated file paths

Avoid source $(command). Unquoted command substitution can split paths on spaces and can source the wrong file if the generator prints extra text. Store the result, quote it, and verify that the path is readable first. This demo selector function prints the environment file created earlier:

select_config() {
    printf '%s\n' './app-env.sh'
}

config_file=$(select_config)

if [ -r "$config_file" ]; then
    source "$config_file"
    printf 'loaded: %s\n' "$APP_ENV"
else
    printf 'Config file not readable: %s\n' "$config_file" >&2
fi

loaded: development

Only use this pattern when the command that selects the file is trusted. A sourced file can run arbitrary shell code.

Source multiple files without glob surprises

When no files match ./configs/*.sh, Bash leaves the unmatched pattern in place unless options such as nullglob are enabled. Guard the loop so the shell does not try to source the literal glob:

for file in ./configs/*.sh; do
    [ -e "$file" ] || continue
    [ -r "$file" ] || continue
    source "$file"
done

This pattern also skips unreadable files. If file order matters, name the files with sortable prefixes such as 10-path.sh and 20-aliases.sh.

Troubleshoot source Command Errors

source: command not found

This usually means the command is running under sh, dash, or another shell that does not provide source. Use the dot command in POSIX shell scripts:

. ./demo-settings.sh

If the file uses Bash-only syntax, run the parent script with Bash instead of forcing it through sh.

No such file or directory

Confirm the current directory and use an explicit relative or absolute path. For files in the current directory, prefer ./filename over a bare filename.

pwd
ls -l ./demo-settings.sh
source ./demo-settings.sh

Variables disappear after the script ends

The file was probably executed in a child shell, such as bash ./file.sh, ./file.sh, or sh ./file.sh. Source the file from the shell that needs the variables, or rewrite the script so it prints values that the caller captures explicitly.

Permission denied

A sourced file does not need the executable bit, but it must be readable. Check ownership and permissions first:

ls -l ./demo-settings.sh

If you own the file and only the read bit is missing, add owner read permission without making the file executable:

chmod u+r ./demo-settings.sh

Clean Up source Demo Files

The examples created files under ~/source-demo. Remove that directory when you are finished testing:

rm -rf ~/source-demo

Conclusion

The current shell can now load setup files, functions, aliases, and optional configuration without losing the changes to a child process. Keep using source for Bash sessions, switch to the dot command for portable sh scripts, and add readability checks before sourcing files selected at runtime.