6.2 Brief introduction to portable sh
If you read a number of `configure.in's, you'll quickly notice that
they tend to be written in an unusual style. For instance, you'll
notice you hardly ever see the `[' program used; instead you'll see
`test' invoked. We won't go into all the details of writing a
portable shell script here; instead we leave that for 22. Writing Portable Bourne Shell.
Like other aspects of portability, the approach you take to writing
shell scripts in `configure.in' and `Makefile.am' should
depend on your goals. Some platforms have notoriously broken
sh implementations. For instance, Ultrix
unset. Of course, the GNU Autotools are written in the
most portable style possible, so as not to limit your possibilities.
Also, it doesn't really make sense to talk about portable
programming in the abstract.
sh by itself does very little; most
actual work is done by separate programs, each with its own potential
portability problems. For instance, some options are not portable
between systems, and some seemingly common programs don't exist on every
system -- so not only do you have to know which
sh constructs are
not portable, but you also must know which programs you can (and cannot)
use, and which options to those programs are portable.
This seems daunting, but in practice it doesn't seem to be too hard to
write portable shell scripts -- once you've internalized the rules.
Unfortunately, this process can take a long time. Meanwhile, a
pragmatic `try and see' approach, while noting other portable code
you've seen elsewhere, works fairly well. Once again, it pays to be
aware of which architectures you'll probably care about -- you will make
different choices if you are writing an extremely portable program like
gcc than if you are writing something that will
only run on various flavors of Linux. Also, the cost of having
unportable code in `configure.in' is relatively low -- in general
it is fairly easy to rewrite pieces on demand as unportable constructs