Mastering Shell Script Reuse: Calling External Scripts and Functions in Linux

Introduction

In Linux development, shell scripts are often written to perform single tasks, leading to many scripts as projects grow. Extracting common functionality into a reusable script reduces duplication and simplifies maintenance.

Ways to Execute an External Script

Assume a.sh contains:

#!/bin/bash

echo "a.sh..."

The following three methods can run a.sh from another script b.sh: source a.sh (or . a.sh) – runs the script in the current shell, inheriting its variables and functions. sh a.sh – spawns a new shell process to run the script. ./a.sh – executes the script as an executable file, equivalent to sh a.sh when the file has execute permission.

Example using source:

#!/bin/bash
source a.sh
echo "b.sh..."

Running ./b.sh prints:

a.sh...
b.sh...

Using the dot notation ( . a.sh) produces the same output, but a space after the dot is mandatory.

Running sh a.sh or ./a.sh also yields the same output, yet the external script runs in a separate process, so its variables and functions are not available to the caller.

Differences Among the Methods

source

and . execute the external script in the current shell, allowing the caller to access its global variables (e.g., VAR_A) and functions (e.g., func_a). In contrast, sh launches a new process; the caller cannot directly use the external script’s variables or functions.

Example demonstrating shared variables:

# a.sh
#!/bin/bash
VAR_A=10
func_a(){ echo "a.sh...pid:$$,param:$1"; }

# b.sh
#!/bin/bash
source a.sh
func_a 5
echo "VAR_A=$VAR_A"

Running ./b.sh 5 shows that VAR_A and func_a are available because they were sourced.

When using sh a.sh, the caller runs in a different process, so attempts to call func_a result in “command not found”.

Calling Functions Defined in an External Script

Because sh isolates the caller, two practical approaches are provided to invoke functions from another script:

1. Case‑Dispatch Method

Define a case block in the reusable script that maps a first argument to a function name.

# a.sh
#!/bin/bash
VAR_A=10

test_a(){ echo "test_a..pid:$$,p1:$1,p2:$2"; }
get_var(){ echo "$VAR_A"; }

case "$1" in
  ta) test_a "$2" "$3" ;;
  var) get_var ;;
  *) echo "parameter err..." ;;
esac

Caller script:

# b.sh
#!/bin/bash
echo "b.sh...pid:$$"
sh a.sh ta 3 5
ret=$(sh a.sh var)
echo "ret:$ret"

This prints the caller’s PID, the function output, and the returned variable value.

2. Generic Function‑Call Template

Append the following snippet to the reusable script so that any function can be invoked directly from the command line without modifying a case block each time a new function is added:

if [ $# -ge 1 ]; then
   name="$1"
   shift 1
   $name "$@"
fi

Full a.sh with the template:

#!/bin/bash
VAR_A=10

test_a(){ echo "test_a..pid:$$,p1:$1,p2:$2"; }
get_var(){ echo "$VAR_A"; }

if [ $# -ge 1 ]; then
   name="$1"
   shift 1
   $name "$@"
fi

Caller script:

# b.sh
#!/bin/bash
echo "b.sh...pid:$$"
sh a.sh test_a 3 5
ret=$(sh a.sh get_var)

Running ./b.sh yields the same results as the case‑dispatch method.

Pros and Cons

Case‑Dispatch : Easy to understand; function name is hidden behind a stable alias, so internal renaming does not affect callers. However, each new function requires an additional case entry.

Generic Template : Callers only need to know the function name and arguments, reducing maintenance when functions change. The downside is that any rename of a function forces updates in all callers.

Conclusion

Reusing shell script code by extracting common functions and variables into a shared script simplifies development and maintenance. Choose source (or .) when you need access to the external script’s environment, and use either a case‑dispatch or a generic function‑call template to invoke specific functions cleanly.