Using dot or "source" while calling another script - what is the difference?

Dot vs. Source: Understanding Script Execution in Bash

Explore the subtle yet critical differences between using . (dot) and source to execute scripts in Bash, and learn when to use each for optimal script behavior and environment management.

In the world of Bash scripting, executing another script from within your current shell is a common task. Two primary commands facilitate this: . (dot) and source. While they often appear interchangeable in simple scenarios, their underlying mechanisms and implications for your shell environment are distinct. Understanding these differences is crucial for writing robust and predictable shell scripts, especially when dealing with environment variables, functions, and aliases.

The Core Difference: Subshell vs. Current Shell

The fundamental distinction between . and source lies in where the target script is executed. When you run a script using ./script.sh or bash script.sh, Bash typically creates a new subshell to execute that script. This subshell inherits the environment of the parent shell but any changes made within the subshell (e.g., setting new variables, changing directories) are confined to that subshell and are lost once the script finishes.

Conversely, both . and source execute the target script within the current shell environment. This means any commands, variable assignments, function definitions, or alias creations within the sourced script directly affect the shell from which it was called. This behavior is often desired when you want a script to modify your current shell's state, such as loading environment variables or defining shell functions.

flowchart TD
    A[Parent Shell] --> B{Execute script.sh}
    B --> C1[Using `./script.sh` or `bash script.sh`]
    C1 --> D1[New Subshell Created]
    D1 --> E1[Script Executes in Subshell]
    E1 --> F1[Subshell Exits, Changes Lost]
    B --> C2[Using `. script.sh` or `source script.sh`]
    C2 --> D2[Script Executes in Current Shell]
    D2 --> E2[Changes Persist in Parent Shell]
    F1 -.-> A
    E2 -.-> A

Comparison of script execution methods and their impact on the shell environment.

When to Use . (Dot)

The . command is a POSIX standard and is universally available in all POSIX-compliant shells, including Bash. It's the most portable way to execute a script in the current shell environment. Its primary use cases include:

• Loading environment variables: If you have a configuration file that defines environment variables (e.g., PATH, LD_LIBRARY_PATH), sourcing it ensures these variables are set in your current shell.
• Defining shell functions and aliases: Scripts that define custom functions or aliases for convenience should be sourced so they become available in your interactive shell session.
• Modifying shell options: Scripts that change shell options (e.g., set -e, shopt -s expand_aliases) will only affect the current shell if sourced.
• Executing startup scripts: Files like .bashrc, .profile, or .bash_profile are typically sourced by the shell upon startup to configure the environment.

#!/bin/bash
# my_env.sh

export MY_VAR="Hello from sourced script"
MY_LOCAL_VAR="This is also set"

my_function() {
  echo "This function is now available!"
}

alias ll='ls -alF'

echo "my_env.sh executed."

Example script (my_env.sh) designed to be sourced.

# In your current shell:
$ . ./my_env.sh
my_env.sh executed.
$ echo $MY_VAR
Hello from sourced script
$ echo $MY_LOCAL_VAR
This is also set
$ my_function
This function is now available!
$ ll
# ... will execute 'ls -alF'

Demonstrating the effect of sourcing my_env.sh.

When to Use source

The source command is a Bash-specific alias for . (dot). It behaves identically to . in Bash. While source is more descriptive and arguably more readable than a single dot, it is not part of the POSIX standard. This means that if you are writing scripts intended to be highly portable across different Unix-like systems and shells (e.g., sh, zsh, ksh), . is the preferred choice. For Bash-specific scripts, source is perfectly acceptable and often used for clarity.

# In your current Bash shell:
$ source ./my_env.sh
my_env.sh executed.
$ echo $MY_VAR
Hello from sourced script
$ my_function
This function is now available!

Using source with the same my_env.sh script.

Common Pitfalls and Best Practices

Understanding when to use . or source versus direct execution is critical to avoid unexpected behavior. Here are some common pitfalls and best practices:

• Unintended Environment Modification: If you execute a script directly (e.g., ./script.sh) that should modify your current shell's environment, those changes will be lost. Always source such scripts.
• Path Resolution: When sourcing a script, Bash searches for it in the PATH if the script name does not contain a slash (/). If it contains a slash, it's treated as a path. Direct execution (e.g., ./script.sh) always requires a path.
• Error Handling: If a sourced script encounters an error and exits, it can potentially terminate your current shell session if set -e is active in the sourced script and not handled carefully. Be mindful of error handling in sourced scripts.
• Security: Sourcing a script executes its commands directly in your shell. Be cautious when sourcing scripts from untrusted sources, as they can execute arbitrary commands with your user's permissions.

Key differences between sourcing and directly executing a script.