Vladimir Serbinenko <[EMAIL PROTECTED]> writes: Hi Vladimir,
>>Last days I have been thinking about scripting support. With my last >>patch it should be easy to implement. I hope Vladimir is still >>interested in this. >> >> > Yes. Exactly now I'm on holiday so I have a lot of time. And also I > have some ideas for some new GRUB features but theese features aren't > useful without scripting so I'm interested more than ever. Nice. >>The most important is the general design. I think we shouldn't put >>too much in the core and not even in normal mode. This is the same >>approach bash has taken. I think the core functionality should be: >> >>- variables (we have that) >>- functions >> Functions should work *exactly* like normal GRUB commands. In >> that case we can easily mix GRUB commands and functions. >> >> > In bash when you define a function it appears under environment > variables. IMHO it's useless to store completely the source code as an > environment variables. I propose that the functions will be preparsed > (converted to internal format ready for execution) because it will > gretelya simplify lexer and parser Right. We should discuss the internal format on the list, I think. >>- Return values >> All commands should be able to return a value. That's also what >> bash has. This value can be stored in a variable or simply >> returned, I am not too sure about that. Just check what bash >> does. >> >> > Could it be merged with error variable. It's what bash does Ok. >>- Conditional statements like if and case >>- loops: until, while and for >> >> >> > I propose the following argorithm. Bison parser transforms the > text-form to internal form of a linked list of commands with some > special commands like jump if last value was true, ... . Think about > assembler. Then it's executed by simple engine that works like CPU: it > takes one command from a linked list. Executes it and changes the > pointer so it points to the next command. A command is a structure > containing: > variable showing it's type (normal command, jump, loop, end of > loop, ...) > union of data necessary for necessary commands > pointer to next command. Right. And this can be kept quite simple. The commands itself are just a string of text. The loops just check a variable, no? It can be something like: for foo in 1 2 3 do echo $i done 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 made a simple example I posted as preview version of scripting > engine and I also posted on this list simple design doc. > Any ideas are welcome. I think I gave you some ideas. ;) Which mail are you talking about (subject and date)? I must have missed a few the last months. :-( -- Marco _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
