Ben is having a rant about shell script portability. When he discovers that not all Unix systems reliably have their Posix, Korn or Bourne shells in the same place "/bin/sh" versus say "/usr/bin/sh", not all "sed" programs have the same name or features, he'll mellow and understand what Larry Wall meant about it being easier to port a shell than a shell script.

In particular Ben is complaining about things like;

$ NAME=jpgfile.jpg
$ NEWNAME=${NAME/%.jpg/.png} # <---
$ echo $NEWNAME
jpgfile.png

Which won't work in some Bourne shell derivatives. At some point one has to stop writing code for Unix 7 and discover you can run the GNU tools pretty much every where. This became apparent for me in the early 90's, when two support calls in quick succession (one to HP, and one to Cray) were both answered with "...the workaround is to use the GNU file utilities", when unsurprisingly I started wondering why HP were still insisting on supporting and shipping their own file utilities, since now I had to support two sets of file utilities, the set we actually used (GNU), and the set the system used during system start-up to avoid compatibility issues.

Portability means different things to different people. Some want a shell script for say installing a program, like the shell archives SUN like to use to distribute software, when you have little choice but to write to the common feature set of the shells and systems likely to be encountered.

But if portability means writing code that won't suddenly be obsoleted or be in need of substantial maintenance due to third party actions, or switching systems, you might discover these goals can be met by using free software instead of merely writing in the set of standardized languages with multiple independent implementations. The much abused concept of "Open Systems" was about achieving the business goal of independence from suppliers - not about adherence to standards for their own sake.

As for the relative merits of interpreted languages, shell scripts don't need a compiler (assuming you can get a binary package with the relevant shell in if it isn't present), and transparency (what does that program does can often be easily answered before running it), and are often easier to debug ("bash -x" for example) as a result.