Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Back: Writing Portable Bourne Shell
Forward: Sh Implementation
FastBack: Writing Portable Bourne Shell
Up: Writing Portable Bourne Shell
FastForward: Writing New Macros for Autoconf
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

22.1 Why Use the Bourne Shell?

Unix has been around for more than thirty years and has splintered into hundreds of small and not so small variants, See section The Diversity of Unix Systems. Much of the subject matter of this book is concerned with how best to approach writing programs which will work on as many of these variants as possible. One of the few programming tools that is absolutely guaranteed to be present on every flavour of Unix in use today is Steve Bourne's original shell, sh -- the Bourne Shell. That is why Libtool is written as a Bourne Shell script, and why the configure files generated by Autoconf are Bourne Shell scripts: they can be executed on all known Unix flavours, and as a bonus on most POSIX based non-Unix operating systems too.

However, there are complications. Over the years, OS vendors have improved Steve Bourne's original shell or have reimplemented it in an almost, but not quite, compatible way. There also a great number of Bourne compatible shells which are often used as a system's default `/bin/sh': ash, bash, bsh, ksh, sh5 and zsh are some that you may come across. For the rest of this chapter, when I say `shell', I mean a Bourne compatible shell.

This leads us to the black art known as portable shell programming, the art of writing a single script which will run correctly through all of these varying implementations of `/bin/sh'. Of course, Unix systems are constantly evolving and new variations are being introduced all the time (and very old systems which have fallen into disuse can perhaps be ignored by the pragmatic). The amount of system knowledge required to write a truly portable shell script is vast, and a great deal of the information that sets a precedent for a given idiom is necessarily second or third (or tenth) hand. Practically, this means that some of the knowledge accumulated in popular portable shell scripts is very probably folklore -- but that doesn't really matter too much, the important thing is that if you adhere to these idioms, you shouldn't have any problems from people who can't run your program on their system.

This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html

  Published under the terms of the Open Publication License Design by Interspire