Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!sheol!throopw From: throopw@sheol.UUCP (Wayne Throop) Newsgroups: comp.os.misc Subject: Re: shell with da Silva lining Summary: suggestion Message-ID: <1563@sheol.UUCP> Date: 2 Apr 91 00:31:14 GMT References: Lines: 85 > peter@ficc.ferranti.com (Peter da Silva) > As an excersize I am in the process of writing a shell for UNIX that only > performs globbing when requested. It is not going to be anything of the > complexity of the regular UNIX shells... sort of a baby shell for novices. > So far the total length of the shell is 472 lines, and it already parses > statements and executes them. No globbing is as yet implemented. What I find missing is what one might call the philosophical underpinnings upon which to evaluate the proposed features of the shell. Starting in by throwing things in it by intuition is OK if it's supposed to be for your own amusement or pure exploration, but if its intended to reflect some need or strategy or whatnot, this need or strategy (or whatnot) needs to be set out right from the start. Of course, one can explore around and change this initial statement based on things found while implementing, but unless it is put down at least fairly explicitly, the result isn't likely to be coherent. Also, if you don't state the rules, you won't know what you've learned when you are done with the excersize. I suggest these "planks" in your proposed platform. 1) Lexical parsimony. The shell should avoid "using up" special characters, so that quotes are rarely necessary. This rule implies things like: there should be only one quotation convention, and any variations shouln't use more special characters. Also, things like comment conventions, line continuation, argument keyword (flag) introduction and the like should be chosen to avoid conflict with common argument text contents (eg: both - and / are rotten choices for keyword introducers (but since the '-' is interpreteted in the commands instead of the shell, alternatives are at best complicated to introduce at this time... (but it's still a goal worth approximating))) Example question: should "variables" and "commands" use (and thus "consume" in the lex-space) completely different special characters to insert values on the command line? 2) Lexical universality. The shell should group arguments in the "cannonical way". That is, while quotation can specify any string as any argument, things like () and [] and "" should group the contained text. Note that the *interpretation* of the string containing the (), [], or whatnot is NOT done by the shell, nor are the grouping characters "recognized" or "processed" in any way. That would be up to some bit of code that knows the meaning of the argument. Things would group in the "obvious way", so for example, (a + b) or func( foo, bar, bletch ) or array[i + 1] would all be single arguments. 3) Lexical locality. The whole distinction between $foo and "$foo" should simply not occur in the way it now does. The blanks inside argument expansions and "backquoted" expansions should not be unconditionally interpreted. To put it another way, characters interpreted by the shell should be apparent at the top level. Now clearly, an "eval" operation is necessary so that one can construct a command out of bits and peices including syntactically significant characters and sic the shell "reader" on it, but this should only occur explicitly. 4) Syntactic simplicity. Syntax for grouping commands, binding values to names, and so on, should follow simple regular rules. No abominations like if..fi, case..esac, do..done (done? you say DONE? ghak! (which illustrates an implication of this rule: your syntax shouldn't overlap your command namespace if you can help it)). Also, introduction of a special syntax simply to bind values is also the Wrong Thing, especially if you also have to execute a command to make this binding "take" for the usual case. Or to put it another way, add functionality by adding semantics, not by adding syntax (where possible). 5) Semantic explicitness. (Note: this is only partly a shell concern.) Implicit functionality should always be utterable explicitly. For example, if specifying something as an empty string is done by not specifying anything at all, it ought to also work to specify "", or $empty-string or whatnot. For another example, it ought to be possible to state explicitly that argument-so-and-so is NOT given. (This makes it much easier to compose operations.) 6) Orthogonality. If you can "foo" something, you better be able to (at least) "un-foo" that something. If you can mumble-east something, you better think about adding mumble-(south|west|north) operations on that same something. And so on. (This is largely an issue for built-in commands, like setenv or rehash or the like.) There are other likely planks, but perhaps this'll start a discussion. -- Wayne Throop ...!mcnc!dg-rtp!sheol!throopw