Include

Include

[Marco Gerards]

Hi,

A lot of people have been asking about an include
command/source/. command.  But I am wondering if it just can be the
same as configfile, except for the cls.

So I will just add the two extra commands to configfile.c if no-one has
a problem with this.

--
Marco

Re: Include

[Yoshinori K. Okuji]

On Saturday 29 April 2006 13:42, Marco Gerards wrote:
> A lot of people have been asking about an include
> command/source/. command.  But I am wondering if it just can be the
> same as configfile, except for the cls.

No. It should be the same as "." in BASH. The command "configfile" is more 
similar to invoking another shell in BASH (i.e. it creates another context, 
while "." is executed in the current context). In this sense, it might be 
better to remove configfile and simply allow the user to "execute" a config 
file (like "grub> (hd0,1)/boot/grub/another.cfg").

Okuji

Re: Include

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> On Saturday 29 April 2006 13:42, Marco Gerards wrote:
>> A lot of people have been asking about an include
>> command/source/. command.  But I am wondering if it just can be the
>> same as configfile, except for the cls.
>
> No. It should be the same as "." in BASH. The command "configfile" is more 
> similar to invoking another shell in BASH (i.e. it creates another context, 
> while "." is executed in the current context). In this sense, it might be 
> better to remove configfile and simply allow the user to "execute" a config 
> file (like "grub> (hd0,1)/boot/grub/another.cfg").

Currently we do not support any context, so it is the same.

I prefer to use some command to execute files.  It makes the parser
simpler and moves code into commands, which are easier to change.

--
Marco

Re: Include

[Yoshinori K. Okuji]

Currently, the commands default, timeout, etc. are ad-hoc, because they can be 
usual variables, but they are commands only for the menu context. I think the 
right way is to make a context for variables (and maybe for funcions as 
well).

This can be implemented differently, that is, using handlers. Handlers can 
change the behavior of each variable arbitrarily. But I'm afraid that this is 
sometimes confusing, and could be a burden, if we want to define more 
menu-specific variables. For instance, I'm considering using variables to 
define a "theme" of the menu interface. This would require a lot of 
variables. If we use handlers, we would have so many special variables... 
IMO, handlers are exceptions, and less exceptions are better to understand 
the system.

So I'd like to make variables more similar to BASH's semantics; by default, 
all variables should be local, and become global only when the user executes 
"export". Then, a reference of a variable means that GRUB first search the 
variable in the current context, then in the global context. This looks 
cleaner than the current implementation.

Okuji

Re: Include

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> So I'd like to make variables more similar to BASH's semantics; by default, 
> all variables should be local, and become global only when the user executes 
> "export". Then, a reference of a variable means that GRUB first search the 
> variable in the current context, then in the global context. This looks 
> cleaner than the current implementation.

Well, I can do that.  It will force some changes to be made in the
kernel (kern/env.c).

I will implement it as follows:

- configfile will execute a script and create a new
  context.
- source/. will execute a script in the current context.

I wonder if we want to have local variables for functions.  With
`local' you can create these in bash.  It will be possible to have
this in GRUB, but will make the implementation bigger and add some
exceptions.

--
Marco