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, and many features added to the original System7 shell are now supported on all interesting porting targets. However, the following discussion between Russ Allbery and Robert Lipe is worth reading:
The GNU assumption that
/bin/shis the one and only shell leads to a permanent deadlock. Vendors don’t want to break users’ existing shell scripts, and there are some corner cases in the Bourne shell that are not completely compatible with a Posix shell. Thus, vendors who have taken this route will never (OK…“never say never”) replace the Bourne shell (as
/bin/sh) with a Posix shell.
This is exactly the problem. While most (at least most System V’s) do have a Bourne shell that accepts shell functions most vendor
/bin/shprograms are not the Posix shell.
So while most modern systems do have a shell somewhere that meets the Posix standard, the challenge is to find it.
For this reason, part of the job of M4sh (see Programming in M4sh)
is to find such a shell. But to prevent trouble, if you’re not using
M4sh you should not take advantage of features that were added after Unix
version 7, circa 1977 (see Systemology); you should not use aliases,
negated character classes, or even
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 you can assume that the shell
has the features that were added in SVR2 (circa 1984), including shell
unset, and I/O redirection for builtins. For
more information, refer to https://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 chapter.
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
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
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.
|• Shellology||A zoology of shells|
|• Invoking the Shell||Invoking the shell as a command|
|• Here-Documents||Quirks and tricks|
|• File Descriptors||FDs and redirections|
|• Signal Handling||Shells, signals, and headaches|
|• File System Conventions||File names|
|• Shell Pattern Matching||Pattern matching|
|• Shell Substitutions||Variable and command expansions|
|• Assignments||Varying side effects of assignments|
|• Parentheses||Parentheses in shell scripts|
|• Slashes||Slashes in shell scripts|
|• Special Shell Variables||Variables you should not change|
|• Shell Functions||What to look out for if you use them|
|• Limitations of Builtins||Portable use of not so portable /bin/sh|
|• Limitations of Usual Tools||Portable use of portable tools|