Vladimir Serbinenko <[EMAIL PROTECTED]> writes: >>That can be translated into some kind of pseudo language: >> >>1: list = 1 2 3 >>2: read i, list >>3: echo $i >>4: check list >>5: je 2 >> >>I know it's stupid and kind of silly like this. But we have to define >>a language. It's important to discuss this on the list, IMO. >> >> >> > I thought about (a):
Right. It's also possible. > The question is how many commands to make: a lot (like in a where > nearly every internal command corresponds to a scripting command) or > make so few commands as possible. I wonder which approach is better > (it's question about bugs and readibility, of course, not about speed) I think we first have to determine: 1) Which commands should be supported. 2) The smallest subset of commands that should be generated. Did you have a look at how bash does this? Perhaps it even has a completely different approach... >>Which mail are you talking about (subject and date)? I must have >>missed a few the last months. :-( >> >> > Re: [Patch] Scripting engine 25.09.2005 > [Patch] Scripting engine 24.08.2005 > It's just demonstration of some ideas. Now I think with new splitter > it would be better to keep arglist unparsed. In this patch it was that > if we have > echo 1 2 3\;\$ ab$i; > lexer returns (schematically) > STRING(echo) STRING(1) STRING(2) STRING (3;$) STRING(abVAR(i)) SEMICOLON > now I would do that it returns: > STRING(echo 1 2 3\;\$ ab$i) SEMICOLON Perhaps the best is to make a list of tokens we need to support. With such list we can determine how to detect them. Thanks, Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
