Chris's Wiki :: blog/programming/BourneShellLimitation

The Bourne shell is not a programming language

May 6, 2008

Before you rise in righteous indignation, let me say that that doesn't mean that you can't write programs in the Bourne shell; you can write programs in anything that's Turing-complete if you try hard enough. It's just that you shouldn't.

The problem with writing programs in the Bourne shell is the same as writing programs in any other highly constrained language: your programs come out all but unreadable because they are spending most of their time getting around the inherent limitations of their environment. What your program is really doing winds up being expressed only indirectly, because you have no good direct way of saying it, and in turn this makes it hard to do anything but run the program and hope it works.

This leads to an obvious question: what's the boundary between a script (which the Bourne shell is fine for) and a program? I'm not sure, but I sort of think that if you need more than a few lines of comments, it's a program.

(Or to put it another way: if it's not obvious what it does and how it works, it's a program.)

Unfortunately I don't think there's a really good Unix programming language to replace the Bourne shell, which is one of the reasons that writing programs in the Bourne shell remains so tempting.

Comments on this page:

From 121.73.68.51 at 2008-05-07 03:20:51:

"Unfortunately I don't think there's a really good Unix programming language to replace the Bourne shell, ..."

While not a replacement for the Bourne shell, and equally (but differently) constrained, the POSIX standard also includes bc(1).

From 209.157.133.146 at 2008-05-07 04:44:41:

Nnngh. I've been trying to tell people at work for some time that cc started life as a shell script, but got turned into C once it got complicated, and I would be willing to bet that it was a lot less of a maze than the thing we're inflicting on ourselves.

But it could be worse, like our gigantic test environment, which uses csh everywhere. They've delayed deploying the next-most-ancient OS version while the vendor figures out why it crashes randomly.

Oh well, there's always m4! I tried that as a MUD front-end very briefly.

More seriously, most new scripting at work uses Python, for which I am duly thankful.

-Smarry

From 194.8.197.205 at 2008-05-07 05:23:49:

A good rant on the general subject:

Today’s Social Issue is this: programmers adore Turing tar pits. Turing tar pits are addictive. You can render programmers completely paralyzed from any practical standpoint by showing them a tar pit and convincing them to jump into it.

—Aristotle Pagaltzis

From 87.198.227.22 at 2008-05-07 06:25:58:

I still maintain that shell only exists as a language simply because languages like perl and python didn't exist at the time - they exist now and that's a good enough reason to avoid doing any programming in sh.

Niall

By cks at 2008-05-11 23:14:22:

I think that the shell is still unmatched if you're quickly gluing stuff together that already mostly exists and just needs some connective work; Perl and Python and so on remain awkward for that.

By John Wiersba at 2018-04-19 13:34:29:

Distinguishing when to stop writing shell and port your script to a "real" language like perl or python is still a matter of judgement and experience. A shell script with too many embedded perl (or other language) fragments is usually a good sign that it should be rewritten. But shell scripting is unbeatable for programs that are mostly file hierarchy manipulation and gluing together streams of data between various programs.

Written on 06 May 2008.

«	The costs of doing your own system administration automation

Today's Solaris 10 irritation: the fault manager daemon