Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!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: recursive eval of command expansion Message-ID: <1685@sheol.UUCP> Date: 15 Apr 91 03:24:39 GMT References: <1563@sheol.UUCP> <60GAP=D@xds13.ferranti.com> <1639@sheol.UUCP> Lines: 69 > peter@ficc.ferranti.com (Peter da Silva) >> But now you run into the question of just how you would utter the >> string "[glob *.c]". > \[glob *.c\] Note that the escape is "merely" an odd-looking quotation convention. So this usage complicates (one could say "pollutes") the simple quotation convention started out with. The escape notation could be rolled up into the eval notation if there were some way to have the results of eval substitution be "born quoted". This drastically expands the lexical simplicity of the whole thing. For example, [asc 012] for newline. Mnemonic instead of numeric versions of the same thing. And so on. Then, the backslash could be used in a more "natural" way inside regular expressions, and in other commands that give it a meaning, rather than having do double up on them, or quote them (with the Politically Correct quote), or whatnot. > You need to be able to specify expansion into multiple args (with glob) > and expansion into a single arg (as in the example above). Yes, I agree. But these notations need not be *introduced* independently, but might more economically (in terms of "how many characters are 'special' in a vanilla context") be variants of a single special case notation. > As for creating a bunch of special characters that mean something after > "[", that's getting back to the original problem I'm attacking here. Well then, let the extra notation be regular, eg [enquote [somecommand]] Thus, the "usual" case would be to rescan, but special cases can be had relatively cleanly, and even user-extensibly. (Though there are some problems with making the enquotation come later... perhaps that ought to be [enquote somecommand] to resolve these little glitches...) > But in regular expressions [] is always paired, and since [] nests and > is passed on, you could easily do: > [glob [a-z]*.c] Hmmmmm. I'd have thought the inner [] would be recursively expanded, so that cases like [wc -l [glob *.c]] could be used easily and naturally to get linecounts as arguments to something. Thus, the inner [a-z] above would conflict. When you had said the notation "nests" in the past I'd assumed you meant recursive expansion. If you didn't want recursive expansion, how would the wc case above be uttered? Something like somecommand [agsh -c 'wc -l [glob *.c]'] to make the recursion explicit? Don't seem natural somehow. > `[...], but how about {...}? Seems OK. Does {foo;bar;bletch} do the "obvious" thing? > Perhaps you could donate a parser for this I'm interested, but my time may be more limited than you'd like. I'm also still trying to get straight what you intend the exact semantics of things to be... you might not like the semantics of any contribution I could give :-). I'll think about it some more and let you know via email. -- Wayne Throop ...!mcnc!dg-rtp!sheol!throopw