Reusing Code with Includes and Sourcing in bash

There are a set of shell variable assignments that you would like to have common across a set of scripts that you are writing.

You tried putting this configuration information in its own script.

But when you run that script from within another script, the values don’t stick; e.g., your configuration is running in another shell, and when that shell exits, so do your values.

Is there some way to run that configuration script within the current shell?

Use the bash shell’s source command or POSIX single period (.) to read in the contents of that configuration file.

The lines of that file will be processed as if encountered in the current script.
Here’s an example of some configuration data:

It is just a simple script consisting of three assignments. Here’s another script, one that will use these values:

and so forth.

The script that is going to use the configuration file uses the source command to read in the file.

It can also use a dot (.) in place of the word source. A dot is easy and quick to type, but hard to notice in a script or screen shot:

You wouldn’t be the first person to look right past the dot and think that the script was just being executed.
bash also has a third syntax, one that comes from the input processor readline, a topic we will not get into here.

We’ll just say that an equivalent action can occur with this syntax:

provided that the file is in your search path (or else specify an explicit path) and that the file has execute permissions and, of course, read permission, too.

That dollar sign is not the command prompt, but part of the directive $include.
Sourcing is both a powerful and a dangerous feature of bash scripting.

It gives you a way to create a configuration file and then share that file among several scripts.

With that mechanism, you can change your configuration by editing one file, not several scripts.
The contents of the configuration file are not limited to simple variable assignment, however.

Any valid shell command is legal syntax, because when you source a file like this, it is simply getting its input from a different source, but it is still the bash shell processing bash commands.

Regardless of what shell commands are in that sourced file, for example loops or invoking other commands, it is all legitimate shell input and will be run as if it were part of your script.
Here’s a modified configuration file:

This configuration file is hardly what one thinks of as a passive list of configured variables.

It can run other commands (e.g., cat) and use if statements to vary its choices. It even ends by echoing a message. Be careful when you source something, as it’s a wide open door into your script.
One of the best uses of sourcing scripts comes when you can define bash functions.

These functions can then be shared as a common library of functions among all the scripts that source the script of function definitions.