./script.sh creates a subshell where variables are lost upon exit. Sourcing with . ./script.sh or source ./script.sh runs commands in the current environment, allowing variable and function sharing. This distinction is critical for managing state across multiple automation tasks.
The Subshell Execution Model
When you invoke a script by its filename or path without any special prefix, the operating system spawns a new child process. In Linux, macOS, and Windows (via WSL or Git Bash), this behavior is standard for executable files. The parent script, which we will calls1, waits for the child script, s2, to finish before continuing. However, because s2 runs in its own memory space, any changes it makes to variables, environment settings, or directory states do not persist in s1.
Consider a scenario where s2 sets a variable named RESULT=success. If s1 executes s2 using ./s2, the variable RESULT will be empty when control returns to s1. This isolation is often desirable for security and stability, ensuring that a faulty script cannot corrupt the state of the main workflow. It is particularly useful when running third-party tools or scripts that might have unintended side effects on your primary session. You can read more about how execution differs across platforms in our guide on Determining Script Execution on Windows, Linux, and MacOS.
The Sourcing Model
Sourcing a script tells the shell to read and execute the commands contained within the target file as if they were typed directly into the calling script. This is done using thesource command or its shorthand dot operator .. Unlike execution, sourcing does not create a new process. Instead, the code runs in the current shell context. This means that any variables defined, modified, or exported in the sourced script remain available after the source command completes.
For example, if s2 defines RESULT=success and s1 uses source ./s2, then s1 can immediately access $RESULT. This mechanism is essential for building modular scripts where configuration, utility functions, or state flags need to be shared between components. It allows you to treat one script as a library of functions rather than a standalone program. Be cautious, however, as sourcing gives the called script full access to your current environment, which can lead to accidental overwrites if variable names conflict.
Practical Implementation Steps
To implement these patterns effectively, follow these specific steps depending on your goal. First, ensure your scripts have the correct permissions. A script must be executable to be run directly, but it only needs to be readable to be sourced. Usechmod +x script.sh for executables. For sourced scripts, readability is sufficient, though making them executable is good practice if they might also be run directly.
Second, structure your code to handle both modes if necessary. You can detect whether a script is being sourced by checking the BASH_SOURCE array. If the length of BASH_SOURCE is greater than one, the script is likely being sourced. This allows you to define functions without executing main logic when imported.
Third, manage paths carefully. When sourcing, use relative paths based on the location of the calling script, not the current working directory. Use SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" to find the absolute path of the current script. Then reference other scripts using "$SCRIPT_DIR/../s2". This prevents errors when the script is invoked from different directories.
Common Pitfalls and Best Practices
One common error is forgetting to make a sourced script executable if you intend to test it directly later. Always verify that the syntax is valid for both modes. Another issue is scope leakage. If you source a script that exports variables, those variables become part of your global environment. To avoid polluting the namespace, limit the scope of variables or use local declarations where possible. Additionally, consider performance. Sourcing avoids the overhead of spawning a new process, which can be beneficial in tight loops or high-frequency automation tasks. However, if the sourced script contains heavy computations, it will block the main script just like execution would. For long-running background tasks, execution is preferable so the main script can continue while the child runs independently. For troubleshooting issues where scripts behave differently as regular users versus logged-in sessions, refer to our article on Troubleshooting: Script Performs Tasks as Regular User but Not Logged.Frequently Asked Questions
Can I pass arguments to a sourced script?
No, sourcing does not accept positional arguments like execution does. The variables $1, $2, etc., inside a sourced script refer to the arguments of the calling script. To pass data, set variables explicitly before sourcing or use a temporary file.
What happens if a sourced script fails?
By default, the shell continues executing the next line in the caller even if a sourced script encounters an error. To stop execution on failure, add set -e at the top of your calling script or check the exit status manually after the source command.
Is there a difference between . and source?
In Bash and Zsh, . and source are identical. However, in older shells like POSIX sh or csh, source may not be supported. Using . provides better compatibility across different Unix-like systems and shell versions.
How do I debug a sourced script?
Use bash -x ./caller.sh to trace execution. Since sourcing runs in the same process, the trace output will interleave commands from both scripts, making it easy to see exactly where variables change or commands fail within the shared context.
Can I source a script from a different directory?
Yes, but you must provide the full or relative path to the file. Relative paths are resolved from the current working directory, not the script's location. Always use absolute paths derived from BASH_SOURCE to ensure reliability regardless of where the caller is executed.