Developing Portable Shell Scripts

Problem

You are writing a shell script that will need to run on multiple versions of multiple Unix or POSIX operating systems.

Solution

First, try using the command built-in with its -p option to find the POSIX version of program, e.g., in /usr/xpg4 or /usr/xpg6 on Solaris:

$ command -p program args

Then, if possible, find the oldest or least capable Unix machine and develop the script on that platform. If you aren’t sure what the least capable platform is, use a BSD variant or Solaris (and the older a version you can find, the better).

Discussion

command -p uses a default path that is guaranteed to find all of the POSIX-standard utilities. If you’re sure your script will only ever run on Linux (famous last words), then don’t worry about it;otherwise, avoid developing cross-platform scripts on Linux or Windows (e.g., via Cygwin).

The problems with writing cross-platform shell scripts on Linux are:

  1. /bin/sh is not the Bourne shell, it’s really /bin/bash in Bourne mode, except when it’s /bin/dash (for example Ubuntu 6.10). Both are very good, but not perfect, and none of the three work exactly the same, which can be very confusing. In particular, the behavior of echo can change.

  2. Linux uses the GNU tools instead of the original Unix tools.

Don’t get us wrong, we love Linux and use it every day. But it isn’t really Unix: it does some things differently, and it has the GNU tools. The GNU tools are great, and that’s the problem. They have a lot of switches and features that aren’t present on other platforms, and your script will break in odd ways no matter how careful you are about that. Conversely, Linux is so compatible with everything that scripts written for any other Unix-like systems will almost always run on it. They may not be perfect (e.g., echo’s default behavior is to display instead of printing a newline), but are often good enough.

There is an ironic Catch-22 here— the more shell features you use, the less you have to depend on external programs that may or may not be there or work as expected. While bash is far more capable than sh, it’s also one of the tools that may or may not be there. Some form of sh will be on virtually any Unix or Unix-like system, but it isn’t always quite what you think it is.

Another Catch-22 is that the GNU long options are much more readable in shell code, but are often not present on other systems. So instead of being able to say sort --field-separator=, unsorted_file > sorted_file, you have to use sort -t, unsorted_file>sorted_file for portability.

But take heart: developing on a non-Linux system is easier than it’s ever been. If you already have and use such systems then this is obviously a nonissue. But if you don’t have such systems in-house, it’s now trivial to get them for free. Solaris and the BSDs all run in virtual environments such as the free VMware Player or Server, which run on Windows or Linux (and soon the Mac).

If you have a Mac running OS X, then you already have BSD—so you’re all set.

You can also easily test scripts using a virtualization environment like VMware. See Testing Scripts in VMware. The flaw in this solution is the systems such as AIX and HP-UX that don’t run on an x86 architecture, and thus don’t run under VMware. Again, if you have these systems, use them. If not, see Getting bash Without Getting bash.

Tip

Debian and Ubuntu users should install the devscripts package (aptitude install devscripts) which provides a checkbashisms script to help find “bashisms” that will not work in dash. Users of other operating systems and/or Linux distributions should see if that is available for their system.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.219.228.88