[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scripting support
From: |
Marco Gerards |
Subject: |
Re: Scripting support |
Date: |
Sat, 22 Oct 2005 17:08:26 +0200 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Vladimir Serbinenko <address@hidden> 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
Re: Scripting support, Yoshinori K. Okuji, 2005/10/27