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: <TB6AKE6@xds13.ferranti.com> <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 \<nl>.
	   I think, though, I need \<space> 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?"
