Limiting the scope of shell state changes

If you are going to change properties of the shell as a whole in part of your script, consider limiting the scope of that change only to the needed part of the script to avoid unexpected effects on the rest of it. Watch for these in particular:

• The working directory
• The positional parameters ($1, $2 ... )
• Environment variables, especially PATH
• Shell-local variables, especially IFS
• Shell options with set (such as -x) or shopt (such as dotglob)
• Shell resource limits set with ulimit

We already saw one effective means of limiting the scope of variables in Chapter 5, Variables and Patterns, by applying them as prefixes to a command:

IFS=: read -r name address

This limits the scope of the IFS change to the read command only.

For other types of shell state change, we have to get a bit more creative:

• Keeping the script itself so short that the change doesn't matter
• Changing the state back to its original value again as soon as possible
• Making the change in a subshell so that it doesn't affect the rest of the program
• Rewriting to avoid the change entirely

The last option is by far the most desirable; if the command itself can do what you need, don't reinvent that wheel in Bash!

Here is an example based on a common problem: the following script changes into the working directory of a Git repository in ~/src/bash, and fetches any changes from its default remote branch:

cd -- "$HOME"/src/bash || exit
git fetch

The problem is that the script needs to change its directory to do this, and then needs to change back to whatever directory it started in before proceeding with the rest of the script.

We could do this manually by saving the current working directory in a variable named pwd before changing it to the repository directory, and then changing back to the saved path after we are done:

pwd=$PWD
cd -- "$HOME"/src/bash || exit
git fetch
cd -- "$pwd" || exit

We could make the change in a subshell, so that it does not change the state of the surrounding script; this is complicated, however, as we then need to add an extra exit to catch a failure to change directory at all, and || true to ignore error conditions from git fetch, since that's what the original does:

(
    cd -- "$HOME"/src/bash || exit
    git fetch || true
) || exit

The best method in this case is to use the git program's  -C option to specify the working directory for the command, allowing us to reduce this to just one line:

git -C "$HOME"/src/bash fetch

If you apply a little care to managing global state like this, your scripts will be much easier to edit later.