Happy Saturday :)
Here's a little humour, from way back when, that's as true today as it was whenever it was originally published. It's a joke (or is it?) that puts forth a bold and visionary alternative to more complicated server page technologies, like ASP, JSP, etc. As the author suggests, it may all be a bunch of sh##, but that's by design ;)
This shining example of a Linux and Unix joke that you can actually put into practice, comes from Mark Lindner's Public Domain Software Site (It's actually his software, that he developed... not a bunch of unclaimed stuff that he put together in one place ;). To check out the original version of this page (including extra specifications, quotations and a bunch of other sh## <-- All this scatological prose will tie in nicely when you read the article, I promise ;), check out the SHSP Project Home Page. For this alone, Mark deserves a contribution. Check out his main page and, if you like this sh##, consider funding his future ...stuff ;)
Enjoy and remember to be kind to animals (even other humans ;)
Bourne Shell Server Pages
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:
- runs everywhere (or at least everywhere on Unix and since I consider
Windows to be nowhere...)
- slo-o-ow
- 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.
—Steve
|
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.
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:
<html>
<body>
<h1><$ echo "Hello, world!" $></h1>
</body>
</html>
|
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.
- Expressions
- 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.
- Includes
- 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:
will be replaced with the result of evaluating the Bourne
Shell Server Page more.shit.
The Bourne Shell Server Pages page compiler (
shspc.sh),
which is tasked with converting
.shit files into shell
scripts, actually consists of a series of
sed commands. These commands perform the following substitutions:
- All contiguous segments of HTML are wrapped within here
documents.
- Include directives are replaced with recursive calls to
shspc.sh to process the included Bourne Shell Server Pages.
- Expression tags are replaced with a call to the shell's
eval command.
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 (in.httpd.sh) 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? |
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.:
<table>
<tr>
<th>Last Name</th>
<th>First Name</th>
<th>Phone</th>
<th>State</th>
</tr>
<$ IFS=','; grep -i $pattern datafile.csv | \
( while read lname fname phone state;
do
$>
<tr>
<td><` $lname `></td>
<td><` $fname `></td>
<td><` $phone `></td>
<td><` $state `></td>
</tr>
<$ ;; done ) $>
</table>
|
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."
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.)
- shspc.sh - page compiler (710 bytes)
- in.httpd.sh - Web server (834 bytes)
Installation is simple. Place the above files in
/usr/local/bin, and then install this href="http">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.
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.
, Mike
Please note that this blog accepts comments via
email only. See our
Mission And Policy Statement for further details.
