Understanding source in Shell Scripts: Why Different Behaviors?

Discover why your shell script produces different results when executed with `source` versus directly in the terminal, and learn how to resolve the issue effectively!
---

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: Weird behaviour when running shell script with `source` and without

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Understanding source in Shell Scripts: Why Different Behaviors?

When we are working with shell scripts, it's not uncommon to run into unexpected results depending on how we execute them. A common point of confusion arises when running a script using source compared to executing it directly in the terminal. If you've ever wondered why your script behaves differently with these two methods, you're not alone! In this guide, we will delve into a specific example and clarify the underlying mechanics, helping you gain a better understanding of shell behavior.

The Problem

Let's start with the script in question. Here is a simple Bash script that takes an argument and processes it:

[[See Video to Reveal this Text or Code Snippet]]

You might expect this script to give the same result regardless of whether it is run with source or by directly calling it. However, you'll find discrepancies in the output:

Execution Results

Using source:

[[See Video to Reveal this Text or Code Snippet]]

Not Using source:

[[See Video to Reveal this Text or Code Snippet]]

As you can see, the output is not the same, which can be quite confusing! So what exactly is leading to this difference?

The Explanation

The key to understanding the difference lies in how source and direct execution operate in regards to the shell environment. Here are the details:

source vs Direct Execution

source: Running a script with the source command executes the script within the current shell process. This means any changes made by the script (e.g., changes to environment variables) affect the current shell directly.

Shell Variables and IFS

The issue you're facing is likely related to the Internal Field Separator (IFS), which is an environmental variable that defines how the shell recognizes word boundaries when splitting strings.

Current Shell Environment: If you've set IFS in your shell configuration (such as .bashrc) to something that doesn't include spaces (e.g., IFS=$'\n'), it directly affects how commands interpret string arguments when invoked through source since it's operating in the same shell.

Subshell Default: When running the script in a subshell (without source), the inherited IFS does not include the modified value, resulting in a different processing behavior. This is why -p and test are treated separately.

The Solution

To remedy this behavior and ensure consistent output when running your script with both methods, you'll want to reset the IFS variable to its default values before running the script.

Here’s how to do it:

[[See Video to Reveal this Text or Code Snippet]]

Conclusion

Understanding how source works in relation to shell scripts is essential for avoiding unexpected behavior in your scripts. By being mindful of changes in the shell environment—especially with critical variables like IFS—you can ensure that your shell commands operate as expected. So next time you're troubleshooting shell scripts, remember that how you execute a script can significantly influence its behavior!

Stay curious and happy scripting!