Re: Scripting support

[Marco Gerards <metgerards@student.han.nl>]

Vladimir Serbinenko <phcoder@gmail.com> 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