Newsgroups: comp.os.misc Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Subject: Re: shell with da Silva lining Message-ID: <60GAP=D@xds13.ferranti.com> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC References: <1563@sheol.UUCP> Date: Wed, 3 Apr 91 00:45:17 GMT In article <1563@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: > 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. Yes, I like this. > 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? No. I'd only use *one* metasequence [...]. The [...[...]...] would nest, but that's that. [set name] would expand to a variable (taken from TCL). > 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. Wouldn't that conflict with [glob *.c], which expands into multiple tokens? > 3) Lexical locality. The whole distinction between $foo and "$foo" > should simply not occur in the way it now does. I'm not sure this is a good idea. I would want [glob *.c] to mean something different than '[glob *.c]'. But, also, I want [glob *] to generate the equivalent of 'baz' 'da foo bar' 'fido' if those are the names of the three files. Perhaps [glob] will have to be written to properly quote stuff for the shell? This might take some thinking about... but it's not desirable otherwise. I was thinking of defining three explicit phases of translation: 1) Statement extraction: the first statement is parsed out of the input stream. Continuations and statement separators are handled here. The only sequence interpreted at this point is backslash-newline. This is properly handled, so that backslash-backslash-newline is passed through. 2) Function evaluation. Functions are evaluated and included literally in the text. Any quotes in the inclusion are doubled or escaped. The only sequences interpreted here are [...] and \[. 3) Argument list generation. The result is broken up into arguments. \x is replaced by x for all x, and not interpreted. This means that both \' and '' will quote a quote: this is not desirable... I wanted it to be strictly '', but it appears that would cause an unfortunate assymetry. The other alternative is to interpret only a particular set of escapes, maybe just \[, \\, and \. I think, though, I need \ as well to properly handle globbing... which quickly leads to excessive complexity. I don't want to abandon the phases of translation model, for a variety of reasons. First of which, of course, being that it makes it easy to describe what the language does. > 4) Syntactic simplicity. Syntax for grouping commands, binding values > to names, and so on, should follow simple regular rules. For sure! But I wasn't going to implement much of this stuff... if you think you need that, may I direct you to TCL which already follows most of your guidelines... if not all... and has the advantage that it already exists. If you want TCL, you have TCL. This sucker is not intended to be a complete command language with loops and stuff, OK? > 5) Semantic explicitness. (Note: this is only partly a shell concern.) Hmmm... > 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.) Hmmm... -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"