148 csh, pipes, and find options that control everything from sort order to the number of columns in which the printout appears—all functions that are better handled with other tools (and once were). The find command writes cpio-formatted output files in addition to finding files (something easily done by connecting the two commands with an infamous Unix pipe). Today, the Unix equivalent of a power drill would have 20 dials and switches, come with a nonstandard plug, require the user to hand-wind the motor coil, and not accept 3/8" or 7/8" drill bits (though this would be documented in the BUGS section of its instruction manual). Unlike the tools in the hardware store, most Unix power tools are flawed (sometimes fatally for files): for example, there is, tar, with its arbitrary 100-characters-in-a-pathname limit, or Unix debuggers, which overwrite your “core” files with their own “core” files when they crash. Unix’s “power tools” are more like power switchblades that slice off the operator’s fingers quickly and efficiently. The Shell Game The inventors of Unix had a great idea: make the command processor be just another user-level program. If users didn’t like the default command processor, they could write their own. More importantly, shells could evolve, presumably so that they could become more powerful, flexible, and easy to use. It was a great idea, but it backfired. The slow accretion of features caused a jumble. Because they weren’t designed, but evolved, the curse of all pro- gramming languages, an installed base of programs, hit them extra hard. As soon as a feature was added to a shell, someone wrote a shell script that depended on that feature, thereby ensuring its survival. Bad ideas and fea- tures don’t die out. The result is today’s plethora of incomplete, incompatible shells (descrip- tions of each shell are from their respective man pages): sh A command programming language that executes commands read from a terminal or a file. jsh Identical [to sh], but with csh-style job control enabled. csh A shell with C-like syntax.
The Shell Game 149 Hardware stores contain screwdrivers or saws made by three or four differ- ent companies that all operate similarly. A typical Unix /bin or /usr/bin directory contains a hundred different kinds of programs, written by dozens of egotistical programmers, each with its own syntax, operating paradigm, rules of use (this one works as a filter, this one works on temporary files, etc.), different strategies for specifying options, and different sets of con- straints. Consider the program grep, with its cousins fgrep and egrep. Which one is fastest?1 Why do these three programs take different options and implement slightly different semantics for the phrase “regular expres- sions”? Why isn’t there just one program that combines the functionality of all three? Who is in charge here? After mastering the dissimilarities between the different commands, and committing the arcane to long-term memory, you’ll still frequently find yourself startled and surprised. A few examples might be in order. Shell crash The following message was posted to an electronic bulletin board of a compiler class at Columbia University.2 Subject: Relevant Unix bug October 11, 1991 Fellow W4115x students— While we’re on the subject of activation records, argu- ment passing, and calling conventions, did you know that typing: !xxx%s%s%s%s%s%s%s%s tcsh Csh with emacs-style editing. ksh KornShell, another command and programming lan- guage. zsh The Z Shell. bash The GNU Bourne-Again SHell. 1Ironically, egrep can be up to 50% faster than fgrep, even though fgrep only uses fixed-length strings that allegedly make the search “fast and compact.” Go figure. 2Forwarded to Gumby by John Hinsdale, who sent it onward to UNIX-HATERS.
Previous Page Next Page