Reusing Code with Includes and Sourcing

Problem

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?

Solution

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:

$ cat myprefs.cfg
SCRATCH_DIR=/var/tmp
IMG_FMT=png
SND_FMT=ogg
$

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

#
# use the user prefs
# source $HOME/myprefs.cfg
cd ${SCRATCH_DIR:-/tmp}
echo You prefer $IMG_FMT image files
echo You prefer $SND_FMT sound files

and so forth.

Discussion

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:

. $HOME/myprefs.cfg

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:

$include $HOME/myprefs.cfg

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:

$ cat myprefs.cfg
SCRATCH_DIR=/var/tmp
IMG_FMT=$(cat $HOME/myimage.pref)
if [ -e /media/mp3 ]
then
        SND_FMT=mp3
else
        SND_FMT=ogg
fi
echo config file loaded
$

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 (as we will show you in Using Configuration Files in a Script). These functions can then be shared as a common library of functions among all the scripts that source the script of function definitions.

See Also

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.119.253.93