You are writing a shell script that will need to run on multiple versions of multiple
Unix or POSIX operating systems.
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:
|
1 |
$ 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).
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 \n 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.
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.
