Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!fernwood!uupsi!ficc!peter From: peter@ficc.ferranti.com (Peter da Silva) Newsgroups: comp.os.misc Subject: Re: shell with da Silva lining Message-ID: Date: 9 Apr 91 17:29:54 GMT References: <1563@sheol.UUCP> <60GAP=D@xds13.ferranti.com> <1639@sheol.UUCP> Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 68 In article <1639@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes: > >> 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 now you run into the question of just how you would utter the > string "[glob *.c]". \[glob *.c\] The thing is, it's not just "[glob *.c]" How about this: fgrep '[cat /etc/foo /etc/bar]' /tmp/database You need to be able to specify expansion into multiple args (with glob) and expansion into a single arg (as in the example above). As for creating a bunch of special characters that mean something after "[", that's getting back to the original problem I'm attacking here. > Finally, in a user-command-oriented shell, using [] for invocation > might be alright... but while (as I said above) I like it, I'm bound > to point out that it conflicts with globbing syntax of [a-z], and > with regular expression syntax. Perhaps {} or `[] might serve > better? But in regular expressions [] is always paired, and since [] nests and is passed on, you could easily do: [glob [a-z]*.c] Perhaps you're right, though. I don't like things like `[...], but how about {...}? > I presume this means that the *output* of glob should be specified > in this way for reparsing, not that argument boundaries found in > any old []-invoked thing are to be frozen by some heuristic... that > is, that glob should supply this smarts, not the shell. This seems > very good. Yes, but on second thought I think I'll make line-feed the terminator for splitting apart lists into arguments. Then glob just has to generate a line-feed separated list of args. This would break for files with linefeeds in the name, but I think that's a minor problem. > It is, I think, possible to interweave function evaluation with > statement and token boundary processing in such a way as to > avoid distinct passes and the problems I see related to them. This is possibly true, but I see the rules becoming quite complex then. Perhaps you could donate a parser for this (would take a string on input, and generate two outputs: a parsed command in argv form if there's enough to specify one, and a pointer to the rest of the string. If the command is incomplete it'd return a pointer to the end of the string and null. I've run into time constraints in the real world, so it's no problem for me to hold off until you have this. > I hope those "hmmmm"s were indicative that what I had to say was > interesting, and not that it gave you reason to question my sanity... Interesting, but not sure what to say. I mean it about that parser. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"