( Portable Shell

Info Catalog ( Run Time ( Writing Tests ( Testing Values and Files
 5.5 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 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.   Utilities in Makefiles (standards)Utilities in
 Makefiles, 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.
Info Catalog ( Run Time ( Writing Tests ( Testing Values and Files
automatically generated byinfo2html