Pet Peeve---Unportable Shell Scripts

In a not-very-recent (March ‘07) edition of the UKUUG newsletter, there’s an article by Clive Darke complaining about the use of external programs to do things that ‘both Bash 3 and ksh93 support’, insisting that you should use the builtins for textual substitution, for example, instead of piping a string through sed.

This is madness. Relying on fancy shell features may improve performance through not having to fork and exec every other line, but it is sick and wrong. It means that all those systems without bash are unable to use your script. In fact, it means all those systems where bash is in a different place are unable to use your script; most people who write bash scripts as opposed to shell scripts seem to assume that bash is /bin/bash, or worse, /bin/sh, which is only common on GNU/Linux systems. It’s even worse in the case of ksh, which is much less widespread on the systems I’ve used, since most versions of it aren’t free software, and there’s several different semi-incompatible versions of it anyway even without getting into the bat-shit-crazy-proprietary-Unix-vendor-extensions that people like Sun and IBM insist upon inflicting on the world.

If performance matters, don’t use a shell script. If performance really matters, you should be using a compiled language anyway, since an interpreted language like shell is always going to be slow.

If portability matters, and you can’t get by with just POSIX sh and sed and awk and everything else, don’t use a shell script. Python, Ruby, Perl, are all designed to behave in the same way across platforms.

(Towards the end, he mentions that it can be more of a challenge to write a good program in ksh than in other languages. I can’t fault him on this, but I’m confused as to why he thinks this is a good thing…)