Re: some design issues

[Serbinenko Vladimir <serbinenko.vova@list.ru>]

Yes this is exactly what I wrote what I spoke about is that when parser 
recognizes a function header it creates a list instead of executing. 
Entry command can not be a normal function because if you write
entry "foo" { for ((i = 0; i < 9; i++)); do echo $i; done }
Normal executing would expand $i before running command that will break 
the function
That's why I parse function by the same engine that loops and conditions.
entry and function are parsed the *same* way only difference is which 
variable engine uses to store it (menu or function list)

Yoshinori K. Okuji wrote:

>On Wednesday 16 February 2005 17:01, Serbinenko Vladimir wrote:
>  
>
>>In my scripting engine entry is parsed the same way that function.
>>Only difference is where contents stored but it's not written as a
>>normal function because it changes a bit the way the input parsed (no
>>expanding, ...) What do you think about it?
>>    
>>
>
>You can treat commands between braces as a group. In bash, a function is 
>defined in the following way:
>
>foo() {
> ...
>}
>
>Or:
>
>function foo {
>  ...
>}
>
>In both cases, the contents enclosed with braces are not evaluated but 
>defined as the body of the function `foo'.
>
>For me, the command `entry' is a kind of shell function. The difference 
>between an entry and a function is that an entry is a part of a menu,  
>while a function is a command. In other words, an entry is an anonymous 
>function which is assigned to a slot in a menu.
>
>So I think a clean way is to pass such a group as a single argument. For 
>example, if the user specifies this:
>
>entry "foo" { kernel /boot/vmlinuz; initrd /boot/initrd }
>
>your parser would invoke grub_cmd_entry with the arguments "foo" and 
>"kernel /boot/vmlinuz; initrd /boot/initd".
>
>If the user specifies this:
>
>function foo { kernel /boot/vmlinuz; initrd /boot/initrd }
>
>it would invoke grub_cmd_function with the argument "foo" and 
>"kernel /boot/vmlinuz; initrd /boot/initd".
>
>This looks consistent to me.
>
>Okuji
>
>  
>

>_______________________________________________
>Grub-devel mailing list
>Grub-devel@gnu.org
>http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>  
>