|
Unix Programming - Language Evaluations - Shell
The ‘Bourne shell’ (sh)
of Version 7 Unix was Unix's first (and for many years its only)
portable interpreted language. Today the ancestral Bourne shell has
largely been displaced by variants of the upward-compatible Korn
Shell
(ksh); the single most important of these
is the Bourne Again Shell, bash.
A few other shells exist and are used interactively, but are not
significant as programming languages; of these, the best known is
probably the C shell csh, which is
notoriously[126] unsuitable for writing
scripts.
Simple shell programs are extremely easy and natural to write.
The Unix tradition of rapid prototyping in interpretive languages
began with shell.
|
I wrote the very first version of netnews as a 150-line
shellscript. It had multiple newsgroups and cross-posting;
newsgroups were directories and cross-posting was implemented
as multiple links to the article. It was far too slow to
use for production, but the flexibility permitted endless
experimentation with the protocol design.
|
|
| --
Steven M. Bellovin
|
|
As program size gets larger, however, they tend to become rather
ad-hoc. Some parts of shell syntax (notably its quoting and
statement-syntax rules) can be very confusing. These drawbacks
generally relate to compromises in the programming-language part of
the shell's design made to preserve its utility as an interactive
command-line interpreter.
Programs are described as being ‘in shell’ even when
they are not pure shell but include heavy use of
C filters like
sort(1)
and of standard text-processing minilanguages like
sed(1)
or
awk(1). This
sort of programming has been in decline for some years, however;
nowadays such elaborate glue logic is generally written in
Perl or
Python, with
shell being reserved for the simplest kinds of wrappers (for which
these languages would be overkill) and system boot-time initialization
scripts (which cannot assume they are available).
Such basic shell programming should be adequately covered in any
introductory Unix book. The Unix Programming
Environment [Kernighan-Pike84] remains one of
the best sources on intermediate and advanced shell programming. Korn
shell implementations or clones are present on every Unix.
Complex shellscripts often have portability problems, not so
much because of the shell itself but because they make assumptions
about what other programs are available as components. While Bourne
and Korn-shell clones have been sporadically available on non-Unix
operating systems, shell programs are not (practically speaking) at
all portable off Unix.
Summing up: shell's best side is that it is very natural and
quick for small scripts. Its worst side is that large shellscripts
depend on lots of auxiliary commands that aren't necessarily
identically behaved nor even present on all target machines. Nor
is it easy to analyze the dependencies in a large shellscript.
It is almost never necessary to build or install a shell, since all
Unix systems and Unix emulators come equipped with them. The standard
shell on Linux and other leading-edge Unix variants is
now bash.
xmlto is a driver script
that calls all the commands needed to render an XML-DocBook document
as HTML, PostScript, plain text, or in any one of several other
formats (we'll take a closer look at DocBook in Chapter18). It is written
in bash.
xmlto handles the details
of calling an XSLT engine with appropriate stylesheet, then handing
off the result to a postprocessor. For HTML and XHTML the XSLT
transformation does the entire job. For plain text, the XML is also
processed into HTML, but then handed to a postprocessor —
lynx(1)
in its -dump mode, which renders HTML to flat text.
For PostScript, the XML is transformed to XML FO (formatting
objects) which a
postprocessor then massages into TeX macros, to DVI format via
tex(1),
and then finally to PostScript via the well-known
dvi2ps(1)
tool.
xmlto consists of a
single front-end shellscript. It calls any one of several script
plugins, each named after the target format. Each plugin is a
shellscript. Depending on how it's called, it either supplies a
stylesheet for the front end to apply, or calls the appropriate
postprocessor(s) with various canned arguments.
This architecture means that all the information about a given
output format lives in one place (the corresponding script plugin), so
adding new output types can be done without disturbing the front-end
code at all.
xmlto is a good example of a
medium-sized shell application. Neither C nor C++ would have made sense
because they are awkward for scripting. Any of the other scripting
languages in this chapter could have been used for this job; but it's
all simple command dispatching, with no internal data structures or
complex logic, so shell is good enough. Shell has the significant
advantage of being ubiquitous on the intended target systems.
In theory this script could run on any system supporting
bash. The real constraint is the
requirement for one of the XSLT engines and all the postprocessors
needed to be present on the system. In practice, this script is not
likely to run anywhere but under one of the modern open-source
Unixes.
Sorcerer GNU/Linux is a Linux distribution that you install as a small,
bootable foothold system just powerful enough to run
bash(1)
and a couple of download utilities. With this code in place, you can
invoke Sorcery, the Sorcerer package system.
Sorcery handles installing, removing, and integrity-checking
software packages. When you “cast spells”, Sorcery
downloads the source code, compiles it, installs it, and saves a list
of files that were installed (along with a build log and checksums for
all the files). Installed packages can be “dispelled” or
removed. Package listing and integrity checks are also available.
More details are available at the Sorcery project site.
The Sorcery system is written entirely in shell. Program
installation procedures tend to be small, simple programs for which
shell is appropriate. In this particular application, the main
drawback of shell is neutralized because Sorcery's authors can
guarantee that the helper programs they need will be present in the
foothold system.
[an error occurred while processing this directive]
|
