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 Bash and the Korn shell
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, as
well; for example, don't rely on ln having a `-f' option or
cat having any options. sed scripts should not contain
comments or use branch labels longer than 8 characters. Don't use
`grep -s' to suppress output, because `grep -s' on System V
does not suppress output, only error messages. Instead, redirect the
standard output and standard error (in case the file doesn't exist) of
grep to `/dev/null'. Check the exit status of grep
to determine whether it found a match.
Go to the first, previous, next, last section, table of contents.