Bourne Shell Server Pages


   "And yet it was a very clever pudding to invent," said the Knight.
   "What did you mean it to be made of?" Alice asked, hoping to cheer him up, for the poor Knight seemed quite low-spirited about it.
   "It began with blotting paper," the Knight answered with a groan.
   "That wouldn't be very nice, I'm afraid—"
   "Not very nice
alone," he interrupted, quite eagerly: "but you've no idea what a difference it makes, mixing it with other things—such as gunpowder and sealing wax."
Every work of art begins with a sudden flash of inspiration. In my case, it all started when I received the following email from my friend, Steve:
Hey Mark:

I just came up with a totally genius idea: Bourne Shell Server Pages.

Why should shell languages be the only ones left out of the ${YOUR_LANGUAGE_HERE} Server Pages fad?

The way I see it, the advantages of SHSPs are as follows:

  1. runs everywhere (or at least everywhere on Unix and since I consider Windows to be nowhere...)
  2. slo-o-ow
  3. goofy

Now most rational people would consider points 2 & 3 to be drawbacks, but as far as I can tell they are flat-out requirements for any popular Web-based technology.

SHSPs are the Wave of the Future, so line up and sign up today!

Tune in next week when we invent 6502 Assembler Server Pages.


Even as I was reading this email, my mind was racing, subconsciously piecing together the implementation details. The Bourne shell, it turns out, is quite well suited for this type of task...much more so, I dare say, than Java or C. The solution turned out to be both simple and elegant.

This document chronicles my foray into the not-so-fascinating world of ${YOUR_LANGUAGE_HERE} Server Pages technology. All of the code I developed is available for free download, so you can use Bourne Shell Server Pages to build your very own killer Web application.


   "It seems very pretty," Alice said when she had finished it, "but it's rather hard to understand! Somehow it seems to fill my head with ideas—only I don't exactly know what they are!"

The basic idea behind all server page technologies is this: rather than writing code that generates an HTML document on-the-fly by writing it out as a series of print statements, you start with a "skeleton" HTML document and embed the code right inside it. Voila! Instead of having a tangled, unreadable, unmaintainable mess of HTML embedded in source code, you have a tangled, unreadable, unmaintainable mess of source code embedded in HTML.

Bourne Shell Server Pages are ordinary ASCII text files, with the special extension .shit, which denotes "Shell-Interpreted Template." The result of invoking the page compiler on a .shit file, is, naturally, a shell script. (It occurred to me that this file extension might seem objectionable to some, but since it quite accurately—if unintentionally—conveyed my sentiments toward Web technology in general, I decided that it should be left unchanged.)

There are three basic elements that can be embedded in HTML: blocks of code, expressions, and include directives. Each of these is indicated by special HTML-like tags which are processed by the page compiler to produce an executable entity (a Java servlet in the case of JSP, for example), which, when run, produces the resulting HTML document. I'll discuss each of these elements in turn.

Code Blocks
Arbitrary blocks of code can be inserted within an HTML document. Bourne Shell Server Pages provides the <$ ... $> tags for this purpose. Shell code that appears between these tags will be executed, and the output of that code will be inlined in the HTML in its place. For example:

            <h1><$ echo "Hello, world!" $></h1>

The code can of course span multiple lines, and can be of arbitrary complexity. What's more, all of the code blocks in a given Bourne Shell Server Page are in reality part of the same shell script, so they share a global state: for instance, a block can reference variables that were assigned in an earlier block.

Arbitrary Bourne Shell expressions can be inserted into HTML using the <` ... `> tags. These tags serve the same purpose as do backticks in the Bourne Shell: the expression is evaluated and the result is inlined in its place. For example, to set the title of the document based on the contents of the shell variable $title, one might do this:

          <title><` $title `></title>

The above example assumes that a value was assigned to the variable $title earlier in the page, namely, within a <$ ... $> block.

Server pages can be composed of other server pages using the include directive. The page compiler evaluates pages recursively, so the nesting can be arbitrarily deep. In Bourne Shell Server Pages, the tag <^ ... ^> indicates an include. For example the tag:

          <^ more.shit ^>

will be replaced with the result of evaluating the Bourne Shell Server Page more.shit.

The Bourne Shell Server Pages page compiler (, which is tasked with converting .shit files into shell scripts, actually consists of a series of sed commands. These commands perform the following substitutions: The result is a script which, when interpreted by the Bourne Shell, produces the desired HTML page to standard output.

Most other server page technologies rely on the presence of a Web server, which is itself a complex piece of software that often requires a substantial amount of maintenance. Bourne Shell Server Pages has no such requirement, as it includes its own Web server, implemented as a small shell script ( that is launched from inetd. While certainly not a full-featured Web server, it does quite an admirable job of serving HTML documents, images, and of course, Bourne Shell Server Pages.

So What About Web Services?

   "Speak English!" said the Eaglet. "I don't know the meaning of half those long words, and what's more, I don't believe you do either!"
How does the Bourne Shell Server Pages technology fit into the bigger picture of Web Services? It's a legitimate question. For that matter, what the hell are "Web Services" anyway?

I've read quite a bit about Web Services, and have had some in-depth, first-hand experience with the technologies that form their underpinnings. To the best of my knowledge, here is an accurate definition of the term:

Web Services  noun  A software development meme that espouses the notion of tying together disparate software components via a crude, non-typesafe, remote procedure call (RPC) mechanism that consists of sending and receiving data encoded in an excessively verbose, plaintext format (XML) over a largely inelegant, stateless file transfer protocol (HTTP).

Whew. That doesn't sound glamorous or exciting at all. It's not even object oriented. There must be more to this than just inferior reinterpretations of old ideas? Sadly, there isn't.

One particularly curious aspect of Web Services is that all communication between components must take place over TCP port 80. The other ports (all 65,534 of them) constitute a veritable Pandora's Box of perceived dangers, horrors and evils, and so Thou Shalt Not Bind Them. It's painfully clear that Web Services exists along three distinct axes: a technical one, an emotional one, and a decidedly religious one.

It turns out that aside from the fact that it employs HTTP, the network protocol of the World Wide Web, Web Services really has nothing to do with the Web. "HTTP Services" would probably be a more appropriate name for the technology. (Sure, that sounds pretty silly...but it is what it is.)

The answer to the thesis of this section is thus very simple: Bourne Shell Server Pages doesn't fit into Web Services, any more than does any other ${YOUR_LANGUAGE_HERE} Server Pages technology.

That being said, Bourne Shell Server Pages is a compelling approach to the problem of providing Web access to existing software components, which incidentally happens to be the major focus of Web Services. Other Web technologies require complex software plumbing in the form of adapters, bridges, and frameworks to expose legacy software systems to the Web. However, due to the radically expressive and flexible nature of the Bourne Shell, Bourne Shell Server Pages makes this problem all but disappear: any program on the system can be invoked from within a Bourne Shell Server Page, its output becoming immediately available on the Web.

For example, providing a Web-based search front-end to a large CSV-data file is almost trivial with Bourne Shell Server Pages, since one can rely on the presence of powerful utility programs for manipulating data, e.g.:

	  <th>Last Name</th>
	  <th>First Name</th>
      <$ IFS=','; grep -i $pattern datafile.csv | \
           ( while read lname fname phone state;

          <td><` $lname `></td>
          <td><` $fname `></td>
          <td><` $phone `></td>
          <td><` $state `></td>

      <$ ;; done ) $>


The true power of Bourne Shell Server Pages stems from the fact that any program can be executed from within a Server Page, with no intermediate "glue" logic required. Think of SHSP as "Web Services without all the layers upon layers of crap."


   "Have some wine," the March Hare said in an encouraging tone.
   Alice looked all around the table, but there was nothing on it but tea. "I don't see any wine," she remarked.
   "There isn't any," said the March Hare.

You, too, can build exciting dynamic Web content with Bourne Shell Server Pages. There are no pre-requisites for deploying the technology other than a working Bourne Shell and a decent operating system to run it on. (Those modest requirements, unfortunately, rule out these products.) - page compiler (710 bytes) - Web server (834 bytes)

Installation is simple. Place the above files in /usr/local/bin, and then install this http file in /etc/xinet.d (or the equivalent). Then send a HUP signal to xinetd. Securing the installation is left as an exercise for the reader.


   "If you didn't sign it," said the King, "that only makes the matter worse. You must have meant some mischief, or else you'd have signed your name like an honest man."
Web technology is certainly a controversial topic. Despite the fact that building Web applications is about as enjoyable as having one's private parts caught in a cement mixer, it continues to be an extremely popular software development paradigm. It's been said that although there is a certain class of problems for which Web technology is the appropriate solution, your problem is almost certainly not among them, no matter what your problem is. But one would be hard-pressed to convince the industry of it.

As do most belief systems, the Web technology religion has its share of rabid followers. In order to avoid their wrath, I remain, humbly and respectfully yours, Anonymous.

Some astute and enterprising readers have graciously submitted bugfixes and improvements for SHSP. I have included these into the official release.