Revision [27]
This is an old revision of Philosophy made by DavidLee on 2007-11-26 09:49:41.
Philosophy
In the opinion of the Author, the Unix "shell" (Wikipedia) is one of the most elegant, practical and powerful command and scripting languages ever written. It has stood up to 30 years of use and abuse, and while it has been copied, cloned, rewritten, duplicated, "improved" and otherwise mimicked in many variants of unix and other operating systems, the core design, functionality, and syntax has not improved significantly, nor needed to be improved. Those who grew up using "modern" Windowing systems or primitive CLI's (Command Line Interpreter) (Wikipedia) may not fully appreciate the elegance and functionality of the unix shell (originally the Bourne shell, /bin/sh) and its variations.
For this discussion the term "Unix Shell" refers to any of the unix shells derived from the Bourne Shell (/bin/sh) although in particular the Bourne Shell as it embodies the earliest and cleanest design. Some offshoots such as the "C Shell" (csh), in an attempt to add features, loose such significant amounts of the original design philosophy. Other languages, such as perl, which were derived, or atleast inspired from, the Unix Shell, are so different that I consider them in their own category as full fledge programming languges.
Unix Shell Design
It is beyond the scope of this document to fully describe in detail the design of the Unix Shell. The following is a rough overview of the major design points which make the Unix Shell elegant, unique and powerful as they implement the philosophy of design. It is these design points and philosophy which xmlsh attempts humbly to borrow from the unix shell. An important consideration and distinguishing factor of a "shell" as apposed to a CLI or a programming language is that a Shell is designed to optimize 2 very different use cases simultaneously. This is a very difficult thing to do and usually fragments computer languages into different categories.For this discussion, I make a distinction between a shell and a login shell.
A quick "litmus test" of a login shell vs some other kind of programming language is would you configure that program to be your 'login shell' on a unix system (the first program that runs when you login). I know many people boast from time to time (myself included) how their favorite program de'jour is so powerful it could be a shell (common examples being perl and emacs) but beyond the occasional playful experimentation, this never happens.
On the other hand a shell may have a bit lower bar if its designed for a subset of tasks, and may not be designed for, or appropreate for everything.
In any case, all shells have the following use cases in mind.
* Command Line Interpreter
A shell must function as a Commmand Line Interpreter. That is, it must funciton well as a primary interface to humans operating a computer using text (keyboard). Early shells ran on "Line Printers" and Teletypes (TTY), and were later modified to work well with "Terminals" (dubbed "Glass TTY's"). Humans type in via a keyboard a "command" to execute and the CLI interprets that command and invokes the necessary process. Dedicated CLI's typically perform this job very well, implementing various sorts of line oriented editing features and simplifications to allow a short command to execute any pre existing process (program) on the computer.
* Scripting
A shell shouild also function as a scripting language. That is, often the process one wants to describe to a compuler is more complex then can be described by typing in a line or 2 without mistakes. CLI's often impliment scripting by allowing multiple lines (identical to what you would have typed in) to be stored in a file and the file executed with one command. This is certianly useful, but it is a tiny step. Usually flow control (if/while/goto), variables, and other more exotic features are needed or desired in order to describe a process. There are many shells and CLI's that manage both of these use cases, but very rarely are both achieved equally well. One hurdle is that typcially the CLI and Scripting cases are not entirely interoperable. That is, you can have commands in a "script" which behave differently when run interactively, or simply are not supported interactively. This makes writing scripts much more difficult then necessary because you cant manually "try out" something intended for a script on the command line. Sometimes this is intential as the shell's authors design philosophy is that scripts are inherantly different then interactive use. Other times it is due to fundimental limitations or design of the operating system. Since shells typically have evolved as the first layer above the OS (and in fact thats why the term "shell" is used), they often reflect the design philosophy of the operating system itself more then their own design.
The Unix Shell adds some additional fundimental design philosophy which is key to its elegance and power.
* The TTY is a file.
In the Unix Shell, the "console" or the "TTY" is considered identical to a file. That is, everything you can do in a script you can do interactively, and visa-versa. This is fundimentally a reflection of the design of the Unix operating system where the console is of the same "type of thing" as a file and for the most part is indistinguishable - they are both a "file" and use the same core system calls to access. While there are a few things you can do to a disk file that you cant do to a tty, and visa versa, both the OS and the Unix Shell attempt to hide these inconsistancies as much as possoble. The end result is that prety much anything you can put into a "script" you can type interactively and it will have exactly the same effect. This merging of the "Scripting" and "CLI" use cases is extremely powerful, and makes authoring, debugging and using scripts a much more simple and natural process then on systems where scripts and CLI behave differently.