Next: , Up: Portable programming   [Contents][Index]

C.1 Portable Shell Programming

When writing your own checks for configure scripts, you should take some care to make your code portable across shells. You should avoid using aliases, negated character classes, or even unset. (These features were added after Unix version 7, circa 1977 (see Systemology).) # comments, while not in Unix version 7, were retrofitted in the original Bourne shell and can be assumed to be part of the least common denominator.

On the other hand, if you’re using M4sh (see Programming in M4sh) you can assume that the shell has the features that were added in SVR2 (circa 1984), including shell functions, return, unset, and I/O redirection for builtins. For more information, refer to http://www.in-ulm.de/~mascheck/bourne/. However, some pitfalls have to be avoided for portable use of these constructs; these will be documented in the rest of this appendix. See in particular Shell Functions and Limitations of Shell Builtins.

Some ancient systems have quite small limits on the length of the ‘#!’ line; for instance, 32 bytes (not including the newline) on SunOS 4. However, these ancient systems are no longer of practical concern.

The set of external programs you should run in a configure script is fairly small. See Utilities in Makefiles in The 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 Limitations of Usual Tools.

There are other sources of documentation about shells. The specification for the Posix Shell Command Language, though more generous than the restrictive shell subset described above, is fairly portable nowadays. Also please see the Shell FAQs.

Next: , Up: Portable programming   [Contents][Index]