10. Portable Shell Programming

When writing your own checks, there are some shell-script programming techniques you should avoid in order to make your code portable. The Bourne shell and upward-compatible shells like the Korn shell and Bash have evolved over the years, but to prevent trouble, do not take advantage of features that were added after UNIX version 7, circa 1977. You should not use shell functions, aliases, negated character classes, or other features that are not found in all Bourne-compatible shells; restrict yourself to the lowest common denominator. Even unset is not supported by all shells! Also, include a space after the exclamation point in interpreter specifications, like this:

#! /usr/bin/perl

If you omit the space before the path, then 4.2BSD based systems (such as Sequent DYNIX) will ignore the line, because they interpret `#! /' as a 4-byte magic number.

The set of external programs you should run in a configure script is fairly small. See section `Utilities in Makefiles' in GNU Coding Standards, for the list. This restriction allows users to start out with a fairly small set of programs and build the rest, avoiding too many interdependencies between packages.

Some of these external utilities have a portable subset of features; see 10.9 Limitations of Usual Tools.

10.1 Shellology		A zoology of shells
10.2 Here-Documents		Quirks and tricks
10.3 File Descriptors		FDs and redirections
10.4 File System Conventions		File- and pathnames
10.5 Shell Substitutions		Variable and command expansions
10.6 Assignments		Varying side effects of assignments
10.7 Special Shell Variables		Variables you should not change
10.8 Limitations of Shell Builtins		Portable use of not so portable /bin/sh
10.9 Limitations of Usual Tools		Portable use of portable tools
10.10 Limitations of Make		Portable Makefiles