The Unix Pestilence: Shells

By Xah Lee. Date:

[ Note: this page is a rant written long ago. For more relevant tutorials, see: Linux Tutorial.]

Shell programming terrifies me. There is something about writing a simple shell script that is just much, much more unpleasant than writing a simple C program, or a simple COMMON LISP program, or a simple Mips assembler program. Is it trying to remember what the rules are for all the different quotes? Is it having to look up the multi-phased interaction between filename expansion, shell variables, quotation, backslashes and alias expansion? Maybe it's having to subsequently look up which of the twenty or thirty flags I need for my grep, sed, and awk invocations. Maybe it just gets on my nerves that I have to run two complete programs simply to count the number of files in a directory (ls | wc -l), which seems like several orders of magnitude more cycles than was really needed. —Olin Shivers, author of scsh, 1994

Command Line Interface is called Shell by unixers. Shell programing refers to programing a “shell program” such as {sh, csh, tcsh, ksh, bash} and the unix tool bag {sed, awk, find, pipe, …}. Today, people are using better tools such as Perl, Python, Scheme languages to perform these tasks, which allows more flexibility, consistency, and speed. Shell programing is quickly becoming a thing of the past. Though, if you are a professional unix sys admin it behooves you to know the basics of shells and unix baggage. Much of unix startup programs and installers are still written in sh.

Of Scheme Shell (scsh) and Python and Perl, scsh is the most easy to learn and powerful. Scheme is a functional language designed by computer mathematicians, but being the least known of the three. Python is also a responsible software, with Object Oriented Programing features and a stable-format syntax. Perl is a evolution from the tradition of unix. It inherits inconsistencies and has lots of problems, however, by itself is nevertheless more coherent and flexible and powerful than all the traditional unix shells and tools bags (sh, csh, tcsh, ksh, bash, sed awk find xargs head tail grep cat chmod et al) combined.

Bash: The GNU Bourne-Again Shell

bash logo
Bash logo.

In unix, there are lots of shells. sh, csh, tcsh, bash and so on. Shell is used for two purposes: ① A command line based interactive control of the OS. ② a scripting/programing control language that automate OS operations. For the latter purpose, today one can use well-designed languages like the Scheme shell or Python. For the interactive use, i advice people to stick to bash, and use it only for interactive purposes. Unless you are a sys admin who must deal with legacy shell script, otherwise it is not worth your time to learn shell programing or the bag of tools.

Scheme Shell

scsh logo
scsh logo

Scheme Shell (scsh) is created by the computer scientist Olin Shivers. The one to blow everything else away. Rectifying the unix stupid shell situation once for all.

Be sure to read the first few chapters Olin Shivers's paper on scsh even if you are not learning scsh. It clarifies many things of unix shells: 〔scsh manual prologue (≈1994) By Olin Shivers. @

Essential Sys Admin by AEleen Frisch, 2nd ed., 1995. amazon

Unix morons tend to regard this book as gift of god. This is relatively not a useful book. This book tries to cover 10 or so varieties of unixes, with the premise that they are on the whole pretty much similar and requires one unified understanding to command a efficient administration. The truth is, different unixes today such as Solaris, HP-UX 11, Mac OS X, Linuxes, AIX, Irix, BSDs… are far from alike for sys admin, from concerns of back up to user account creation to network setup et al each has a specific modus operandi incompatible with each other. (even for command-line executions are different (ptree/pstree, top, useradd/adduser,tar, ps auwwx/ef, hardware info, boot mechanism…, shut down procedure, file systems).). The only thing they have in common today is the baggage of unix tools (shell & friends), which today are pretty much supplanted by more competent tools and methodologies such as Perl and specific GUI applications.

This book chapter 3 is free online, a intro to some unix tools for sys admin (Local copy Essential_Sys_Admin_by_AEleen_Frisch.txt)

In this chapter, you'll see lots of unixy drivel. Things like “right tool for the right job” and other asinine chant phrases and maxims. The tools mentioned in that page are fcking salient kludges. The thing is, if you are unix admin, you gotta dumb down your fathoming faculty and rote rote rote.

The best unix sys admin books, are those manuals published by the specific unixes in question. Each particular unix such as Solaris, HP-UX, Mac OS X all have sys admin docs published by their respective companies, free on their websites. One may think that unixes are basically all the same. That is true only at the user-level.

Unix's environment variable system

Unix's environment variable system is a pus that grows and propagate. See: Why LD_LIBRARY_PATH is bad for one example.

The unix env var is a giant global variable system. Take my advise: If you write unix programs, never command users or installer to set env vars. Your program should run and behave absolutely independent of user's environment variables. Let any input take the form of arguments or config files. The fcking unixers cannot understand why. They need to ponder on the nature of global variables.

The Apache group has a ok explanation on Dynamic Shared Object, by Ralf S Engelschall, 1998. (local copy)

On Unix file system case sensitivity by Brian Tiemann, 2002

Even though there are tons of unix info online, there are some unix books worth buying for one reason or another. Here's a few i recommend. (some are available online.)

Unix Power Tools book cover
UNIX Power Toolsby Jerry D. Peek, Tim O'Reilly, Mike Loukides. amazon

This is a germ. It's a collection of technical articles, most of which originated from early online era (USENET). It's a very thick book. 1120 pages. One of the first few books from O'Reilly. This is for experienced unix users. Say, at least 1 year unix experience. You will learn a lots of tidbits there to deepen and appreciate just how antique and convoluted unixes are. Much of what you learn from this book is command line tricks. If your goal is being efficient in what command line and shell can do, it is better to learn a language that has tight unix integration, such as Python and scsh.

Jerry D Peek has a website at: