Shell variable scoping defines the accessibility range of a variable within a specific context. In Bash, variables are categorized into three primary types based on their visibility:

1. Local Variables: Restricted to the current function or block execution.
2. Global Variables: Accessible throughout the entire duration of the current shell process.
3. Environment Variables: Exported from the parent shell to any spawned child processes.

Local Variable Mechanics

By default, assigning a variable inside a shell function assigns it to the global scope, making it visible outside the function. To restrict visibility strictly to the function, the local keyword must be used.

Without local Keyword (Global Scope)

process_data() {
    temp_value=404
}

process_data
echo "External value: $temp_value" 
# Output will show 404

In this example, temp_value becomes part of the global environment immediately after the function call.

With local Keyword (Encapsulated Scope)

process_data_encapsulated() {
    local temp_value=404
}

process_data_encapsulated
echo "External value: ${temp_value:-undefined}"
# Output will remain undefined/empty

Using local ensures the variable does not leak into the caller's scope.

Global Variables and Process Context

A global variable exists only for the lifetime of the current Shell process. Since each terminal window typically represents a separate process with its own Process ID (PID), variables defined in one window do not carry over to another without export.

However, scripts executed within the same process can share these globals. For instance, if script A sets a variable and is sourced by script B, that variable remains available.

Common Execution Pitfalls

A frequent error occurs when modifying variables inside pipelines. Piping data into a loop spawns a subshell. Any changes made to variables within that loop exist only in the subshell and disappear upon completion.

Incorrect (Subshell Issue):

count=0
cat /data/input.log | while read line; do
    count=$((count + 1))
done
echo "Total lines: $count" # Prints 0

Correct (Direct Redirection):

count=0
while read line; do
    count=$((count + 1))
done < /data/input.log
echo "Total lines: $count" # Prints correct count

Script Execution Methods

Understanding how a script is invoked is critical for variable inheritance.

Method	Context Created	PID Change	Scope Impact
./script.sh	New Subshell	Yes ($$ changes)	Variables lost after exit
sh script.sh	New Subshell	Yes ($$ changes)	Variables lost after exit
. ./script.sh or source	Current Process	No ($$ stable)	Variables persist in caller

When executing via . or source, the script runs in the current shell memory. This is required when setting up environment variables intended for use in subsequent commands within the same session.

Environment Variables

To pass data to child processes, a global variable must be explicitly exported using export. Once exported, the variable becomes part of the process environment table.

Demonstration:

$ export MY_VAR="Hello"
$ bash          # Start child shell
$ echo $MY_VAR  # Result: Hello
$ exit
$ echo $MY_VAR  # Result: empty

Exported variables persist only while the parent session is active. If the root shell exits, the exported history is cleared unless saved to configuration files.

Startup Configuration Files

To ensure variables persist across sessions, they must be defined in initialization scripts loaded at startup.

Login Shells

A login shell loads resources in the following order:

1. /etc/profile (System-wide defaults)
2. User-specific configs in home directory (Priority applies):
   • ~/.bash_profile
   • ~/.bash_login
   • ~/.profile

Bash executes the first existing file found among the user-level profiles. Typically, ~/.bash_profile is configured to source other files like ~/.bashrc.

if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

Non-Login Interactive Shells

Terminal windows opened directly often run as non-login shells. These bypass the profile files listed above and load ~/.bashrc directly. It is common practice to define aliases and environment variables there to apply them consistently regardless of shell type.

Some configurations also nest load /etc/bashrc with in ~/.bashrc to inherit system-wide defaults.