Scripting (IMPORTANT!)

Scripting (IMPORTANT!)

[Marco Gerards]

Hi,

As you noticed I put important in the topic.  I personally consider
scripting one of the most important features that has to be
implemented before GRUB 2 can be used in distributions.

It's also one of the features that we all have to talk about before we
determine it will not be changed.  After GRUB 2 is being used by
everyone it will be hard, if not impossible, to make changes that make
different GRUB 2 versions incompatible.

So it is important that most active developers read my ideas about
scripting and what I currently implemented.  As you might have
noticed, I wrote this in little time and thus it will be a bit chaotic
and it is not well written.  But I hope I can start this important
discussion this way.

Another thing I want to discuss soon is using "cd" and "pwd" commands
to change the current directory instead of what we have now.  I would
like to make this change as well.

I'm looking forwards to your ideas, questions, suggestions, criticism
and bug reports. :-)

--
Marco


=========
Variables
=========

In GRUB 2 there are two types of variables.  The difference is like in
bash: the scope.  Variables either have a local or global (exported)
scope.  Initially all new added variables have the local scope.  By
using the export command they can be made global.

Some variables have a special purpose and will be created by GRUB.
These are:

- root: The active disk/partition (rw, global)
- prefix: The pathname used to load grub.cfg and the modules (rw, global)
- platform: Set to the platform, eg. EFI, IEEE1275, PCBIOS, etc. (ro, global)
- processor: Processor architecture GRUB was compiled for, eg. PPC, x86 (ro, global).
- debug: Print debugging messages for certain parts of the code, or
  all messages when set to all.  (rw, global?)
- pager: When set to `1', wait for a key when the bottom of the screen was reached.

(more will be added, like variables to read time/date, random, etc)

To include a file two commands can be used.  The first is source,
which does not change the scope.  The second is `configfile' which
opens a new scope.

Variables can be used like in bash.  You can use set to set or list
variables.  Explicit assignments (`foo=bar' instead of `set foo=bar')
is possible.  You can include variables in command lines by using the
`$' prefix, for example $foo.  To use it to concatenate variable
contents and text, you can use the ${foo} syntax.  Sometimes you want
to use the `$' in commands (for example, multiboot lines for the Hurd)
without meaning a variable, in that case you can use single quotes for
escaping (for example, '$foo').

==> Currently unimplemented: The export command, special variables
    other than root, prefix, debug and pager.  Concatenating with
    variables is currently broken.

=========
Functions
=========

Functions can be created as follows:

function funcname { code }

After that they can be called just like any other command.

Arguments can be passed to functions.  In the function body they can
be accessed as in bash ($1, $2, etc).

==> Currently unimplemented: Function arguments.

==> Idea: Exporting functions to be full featured commands that can be
    tab completed, documented, etc.  This way functions can be
    implemented by scripts instead of C code.

====
 If
====

The if command is also quite similar to the if command in bash.  It
has the following syntax:

if command ; then commands fi
OR:
if command ; then commands else commands fi

The command that follows the if contains the condition that is tested
for.  You can use any command and check the return status like this.
The most useful command to use here is the `test' (or `[') command.
It is similar to the test command in bash, although it can not check
for certain filesystem bits like file protection and certain
filetypes.

==> Currently unimplemented: The test command (although it is almost
    finished).

============
Menu entries
============

Menu entries are added with `menuentry' (or its alias `@').  It's
important to notice this is not a command.  Because it's part of the
scripting syntax, it can have unique features.  A menuentry is like a
function, especially because it can have arguments!

Syntax: menuentry "Entry name" [arguments...] { body }

Make sure the entry name is properly escaped, otherwise spaces can not
be included and will be seen as separator.  The arguments will become
semi-variables like #1, #2, etc.  These can be used so one menuentry
can be used as a template for a lot of menuentries.  This can best be
explained with an example:

(inside loop that sets i = 1...x)
@ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }

This will set #1 to $i (it's the first argument).  The menuentry
command is executed for i=1...9 and will generate 9 different menu
entries.  This is useful for automatic generation of menu entries.

==> Currently unimplemented: Arguments for automatic generation of
    menuentries.
==> Discussion: Perhaps I will change the #1 into $1, although this is
    not really a variable.

=====
 for
=====

The for command can be used to iterate over a set of data.  I don't
like the idea of implementing this *exactly* like in bash.  Personally
I am thinking of the following syntax:

Iterating over files:
for x in (hd0,3)/foo/* ; do commands ; done

The commands will be executed for each file in the directory.

Iterating over disks:
for x in (*) ; do commands ; done

Iterating over partitions:
for x in (*,*); do commands ; done

An alternative syntax which I think is more natural could be:

foreach x in files ; do commands ; done
foreach x in disks ; do commands ; done
foreach x in partitions (hd0) ; do commands ; done
foreach x in modules ; do commands ; done

The foreach syntax makes it possible to add named iterators with
arguments.  In that case modules can be written that add new
iterators.  Perhaps even scrips can be used for this.  I don't like
the idea of using the standard output of files for this, because I am
afraid this will get messy and tricky.

==> Currently unimplemented: All of this.

===========================
 Other language constructs
===========================

Other language constructs can and will be implemented.  Like: elif,
 while, case, select, etc.
  
==> Currently unimplemented: All these constructs.

===============================
 Commands useful for scripting
===============================

- echo: Prints text.
- cmp: Compares files.
- configfile/source: Including other files.
- search: Search for files, labels, etc. and set a variable.
- test: Test certain conditions.

==> Currently unimplemented: Echo can't "beep".

================
 Error handling
================

Every command can return an error value.  This error value will be
available as $?.  This variable will be checked by if, while, etc.  In
scripts all parsing errors will be non fatal so the system is not left
unbootable.

Unparsable menu entries will be added, but will not be executable,
only the editor is available.

One special purpose variable $ERROR will be added.  It will contain
the error strings when $? is set to non-zero.  In that case you can do
error handling in scripts.

After every command an error is printed by default.  You don't want
this to be silent, otherwise users can not detect errors.  But it
should be able to set error handling to silent because a certain
script or function does its own error handling.  This can be done by
setting $ERRORS=0 (default it is set to 1).

==> Currently unimplemented: $ERROR, $ERRORS, a lot of this logic is
    far from perfect.

Re: Scripting (IMPORTANT!)

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

Marco Gerards <mgerards@xs4all.nl> writes:

> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done

I must say I would prefer this over the other ("foreach") suggestion,
since I'm more used to it. 

Anyhow, is your plan to make expansion available through out the whole
shell, or only for "for"?  It would be nice to be able to do;

 grub> ls (*,*)/boot/vmlinuz*

> One special purpose variable $ERROR will be added.  It will contain
> the error strings when $? is set to non-zero.  In that case you can do
> error handling in scripts.

I'm afraid there might be situations where the user do not realize
that $ERROR has been overwritten.  Bogus example;

  if cat (hd0,1)/foo/bar; then 
    ls (hd0,1)/foo
    echo "*** 'bar' is missing: $ERROR"
  fi

The execution of 'ls' will overwrite $ERROR.

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: Scripting (IMPORTANT!)

[Johan Rydberg]

[-- Attachment #1: Type: text/plain, Size: 174 bytes --]

Marco Gerards <mgerards@xs4all.nl> writes:

> =========
> Variables
> =========
>
> - root: The active disk/partition (rw, global)
> ...

What about a 'prompt' variable?

~j

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

Re: grub2 file browser draft

[adrian15]

> I noticed you mention hda1 here, which is a Linux device name.  I have
> explained you before it is technically not possible to translate GRUB
> device names to Linux device names.  I wish it was possible, but
> unfortunately it currently isn't because the BIOS is used to access
> harddisks.

I am sorry, I did not want to start over the discussion. I just wanted 
to know if given a hard disk device we could iterate over its partitions 
or at least generate a menu from them.

I've seen that you say we cannot iterate over files so I supose that it 
also means that we cannot iterate over partitions yet.

adrian15

Re: grub2 file browser draft

[Marco Gerards]

adrian15 <adrian15@raulete.net> writes:

>> I noticed you mention hda1 here, which is a Linux device name.  I have
>> explained you before it is technically not possible to translate GRUB
>> device names to Linux device names.  I wish it was possible, but
>> unfortunately it currently isn't because the BIOS is used to access
>> harddisks.
>
> I am sorry, I did not want to start over the discussion. I just wanted
> to know if given a hard disk device we could iterate over its
> partitions or at least generate a menu from them.
>
> I've seen that you say we cannot iterate over files so I supose that
> it also means that we cannot iterate over partitions yet.

Please read my other email about scripting.  I assume all your
possible questions are answered there, otherwise please ask.

--
Marco

Re: Scripting (IMPORTANT!)

[adrian15]

> Hi,
> - root: The active disk/partition (rw, global)
> - prefix: The pathname used to load grub.cfg and the modules (rw, global)
> - platform: Set to the platform, eg. EFI, IEEE1275, PCBIOS, etc. (ro, global)
> - processor: Processor architecture GRUB was compiled for, eg. PPC, x86 (ro, global).
> - debug: Print debugging messages for certain parts of the code, or
>   all messages when set to all.  (rw, global?)
> - pager: When set to `1', wait for a key when the bottom of the screen was reached.

Marco, my problems comes when I want to load with configfile and source 
many files from a grub2 cdrom. I just want to make sure that I am 
loading from the cdrom but not from another place.

Currently I use something like this in SGD:

configfile $(grub_device)/my_folder/myfile.lst

$(grub_device) is a variable that stores (cd), (fd0) or (hd0) depending 
from which place has SGD booted.

Let's suppose that you can change grub2's root variable with the ROOTC 
command (I do not know which it is the legacy's root equivalent in 
grub2, I will name it ROOTC in order to distinguish it from the variable).
Let's see an example. You boot from a cd. root is (cd). Then you select 
a menu that loads a configfile file from the hard disk. So root is 
changed to (hd0,0). Ok...

If there is an error and want to come back to my menues... How can I 
change the root variable back so that something as:

configfile ${root}/my_folder/myfile.lst

works as expected (loading a file from the cdrom not from the hard disk).

CONCLUSION: I would add a grub_device or first_boot_device variable.

> function funcname { code }
 > if command ; then commands fi
 > for x in (*) ; do commands ; done

A question arises to me... Do we have to type this commands in a single 
line or can we write them in multiple lines?


> Arguments can be passed to functions.  In the function body they can
> be accessed as in bash ($1, $2, etc).

I do not know why this should be useful... but would $0 return the name 
of the function?

> ==> Idea: Exporting functions to be full featured commands that can be
>     tab completed, documented, etc.  This way functions can be
>     implemented by scripts instead of C code.
Yes, please. If I need a more complex search command, I will need to 
implement it as a function and thus I will use it in a lot of scripts 
and exporting it would be a good idea.

> ============
> Menu entries
> ============
> ==> Discussion: Perhaps I will change the #1 into $1, although this is
>     not really a variable.
This is interesting. If I was myself coding I will choose the #1 syntax. 
However I suppose that people will get used to the $1 and will 
understand better the $1 syntax. I think it is better the $1 syntax.

However, let's see a problematic example.

function boot_linux_part_menu_gen {

begins loop that sets i = 1...x
@ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
ends loop that sets i = 1...x

}

Sorry... Let's use the another syntax...

function boot_linux_part_menu_gen {

begins loop that sets i = 1...x
@ "Partition $i" $i { linux /vmlinuz root=/dev/hda${1} }
ends loop that sets i = 1...x

}

VOILA... ${1} refers to the boot_linux_part_menu_gen function first 
argument or to the Partition mennu first argument ?

My final vote is for the #{1} syntax for the sake of simplicity.

> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done

I think we need an start variable and a max variable for generating 
menus from big folders.

I do not know which it is the number of files of /etc folder in linux 
folders but I think it is very big.

The idea is with a start=0 show 20 files (like search engines) in a menu 
and the last entry calls the same menu generator function with the:
start=20 show 20 files argument so that we can see the next 20 files.

This will remove memory-eating problems I think.

> foreach x in files ; do commands ; done

I would improve this like this:

foreach x in files ($folder) ; do commands ; done
> From: Johan Rydberg 
> What about a 'prompt' variable?

I think that fits into the cd and pwd discussion that M. Gerards wanted 
to start.

In my opinnion there should be a pwd variable for each of the scopes of 
grub.

By the way...

I configfile one.cfg
 From one.cfg I source two.cfg.
Then from two.cfg I configfile three.cfg.
Then from the three.cfg the hipotetical exit command is run do we return 
to the middle of one.cfg execution or not ?

A question... Will I be able to use relative paths (./, ../path/)at last?

adrian15

Re: Scripting (IMPORTANT!)

[Marco Gerards]

adrian15 <adrian15@raulete.net> writes:

Hi,

> Marco, my problems comes when I want to load with configfile and
> source many files from a grub2 cdrom. I just want to make sure that I
> am loading from the cdrom but not from another place.
>
> Currently I use something like this in SGD:
>
> configfile $(grub_device)/my_folder/myfile.lst
>
> $(grub_device) is a variable that stores (cd), (fd0) or (hd0)
> depending from which place has SGD booted.
>
> Let's suppose that you can change grub2's root variable with the ROOTC
> command (I do not know which it is the legacy's root equivalent in
> grub2, I will name it ROOTC in order to distinguish it from the
> variable).

In GRUB 2 root is a variable which you can change like any other
variable, no need to use a command.

> Let's see an example. You boot from a cd. root is (cd). Then you
> select a menu that loads a configfile file from the hard disk. So root
> is changed to (hd0,0). Ok...

Why would root be changed by this?  Because the configuration file
does this?

> If there is an error and want to come back to my menues... How can I
> change the root variable back so that something as:
>
> configfile ${root}/my_folder/myfile.lst
>
> works as expected (loading a file from the cdrom not from the hard disk).
>
> CONCLUSION: I would add a grub_device or first_boot_device variable.

I see the problem, but draw a different conclusion.  Either root
should not be an exported variable (which can cause other problems),
or you have to use temporary variables which means GRUB 2 does not
have to be changed.

>> function funcname { code }
>> if command ; then commands fi
>> for x in (*) ; do commands ; done
>
> A question arises to me... Do we have to type this commands in a
> single line or can we write them in multiple lines?

It's possible to use multiple lines.

>> Arguments can be passed to functions.  In the function body they can
>> be accessed as in bash ($1, $2, etc).
>
> I do not know why this should be useful... but would $0 return the
> name of the function?

Yes.

>> ==> Idea: Exporting functions to be full featured commands that can be
>>     tab completed, documented, etc.  This way functions can be
>>     implemented by scripts instead of C code.
> Yes, please. If I need a more complex search command, I will need to
> implement it as a function and thus I will use it in a lot of scripts
> and exporting it would be a good idea.

Well, exporting here means that it will be integrated fully.  It
doesn't mean that if it is not exported, it will not be available.
The difference is that when you export it, or transform it to a
command it will be fancy.  In that case the function HAS TO DO
argument parsing, export help texts, etc.  I don't think you will
really need this.

[...]

> VOILA... ${1} refers to the boot_linux_part_menu_gen function first
> argument or to the Partition mennu first argument ?

In that case the one for the menu entry.

>> Iterating over files:
>> for x in (hd0,3)/foo/* ; do commands ; done
>
> I think we need an start variable and a max variable for generating
> menus from big folders.

You can better solve this using `if'.  I think we also need the `expr'
command, which I will add to my todo.  In that case you can just count
and break out of the loop when you are done.  I will have a look how
one would do this when using bash.

> By the way...
>
> I configfile one.cfg
> From one.cfg I source two.cfg.
> Then from two.cfg I configfile three.cfg.
> Then from the three.cfg the hipotetical exit command is run do we
> return to the middle of one.cfg execution or not ?

Yes.

> A question... Will I be able to use relative paths (./, ../path/)at last?

This is implemented already, IIRC.  Why wouldn't this work?  The . and
.. are just regular directory entries.  In some filesystems like the
iso9660 filesystem I just "simulate" them.

--
Marco

Re: Scripting (IMPORTANT!)

[tgingold]

Quoting Marco Gerards <mgerards@xs4all.nl>:

Hi,

a few remarks:
[...]
> ============
> Menu entries
> ============
>
> Menu entries are added with `menuentry' (or its alias `@').  It's
> important to notice this is not a command.  Because it's part of the
> scripting syntax, it can have unique features.  A menuentry is like a
> function, especially because it can have arguments!
>
> Syntax: menuentry "Entry name" [arguments...] { body }
It would be nice to be able to add properties to a menuentry.  My first
idea is a logo property.
I think this could be done through a new command such as:
logo "Entry name" filename

> Make sure the entry name is properly escaped, otherwise spaces can not
> be included and will be seen as separator.  The arguments will become
> semi-variables like #1, #2, etc.  These can be used so one menuentry
> can be used as a template for a lot of menuentries.  This can best be
> explained with an example:
>
> (inside loop that sets i = 1...x)
> @ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
Why not substituing variable at creation (unsubstitued one can be escaped) ?
Eg: @ "Partition $i" { linux /vmlinux root=/dev/hda$1 prefix=$$prefix }
Humm maybe too complex ?

Tristan.

Re: Scripting (IMPORTANT!)

[Hollis Blanchard]

On Thu, 2006-10-05 at 15:41 +0200, Marco Gerards wrote:
> I'm looking forwards to your ideas, questions, suggestions, criticism
> and bug reports. :-)

How hard do you think it will be to implement all these features (and
handle the bugs)?

I wonder if we wouldn't be better served by a simpler scripting
language, rather than trying to emulate bash.

-Hollis

Re: Scripting (IMPORTANT!)

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Thu, 2006-10-05 at 15:41 +0200, Marco Gerards wrote:
>> I'm looking forwards to your ideas, questions, suggestions, criticism
>> and bug reports. :-)
>
> How hard do you think it will be to implement all these features (and
> handle the bugs)?

Most of it is implemented already.  Other features will be
implemented.

Some things are easy to implement.  Like the test and expr commands.
I hope I can move the iterators to modules as well.  Modules are
easier to maintain, because of its interfaces.

But of course there are things that I do not like, when talking about
maintainability:

- The lexer is handcoded, I prefer a generated scanner.
- Preventing memory leaks is annoying.
- Perhaps more thoughts about error handling is required.


> I wonder if we wouldn't be better served by a simpler scripting
> language, rather than trying to emulate bash.

I think it is simple already.  But suggestions to make the code easier
to read, increase maintainability and flexibility are always welcome.

--
Marco

Re: Scripting (IMPORTANT!)

[Yoshinori K. Okuji]

On Thursday 05 October 2006 15:41, Marco Gerards wrote:
> It's also one of the features that we all have to talk about before we
> determine it will not be changed.  After GRUB 2 is being used by
> everyone it will be hard, if not impossible, to make changes that make
> different GRUB 2 versions incompatible.

I agree. And I believe that GRUB should follow BASH whenever reasonable, so 
that the user does not have to learn new things only for GRUB. Inventing a 
new syntax is something I dislike. Also, I believe that one should write a 
new module if she wants another language in GRUB, and execute it by a 
command, as in GNU.

> Another thing I want to discuss soon is using "cd" and "pwd" commands
> to change the current directory instead of what we have now.  I would
> like to make this change as well.

I thought the same thing before, but I didn't, because the effect of setting 
the root device has a different meaning, that is, to set a boot device for 
the chainloader. Besides this, the root variable is very similar to the 
concept of "current working directory" in Unix. So I wouldn't object 
strongly, even if you change it this way.

> =========
> Variables
> =========
>
> In GRUB 2 there are two types of variables.  The difference is like in
> bash: the scope.  Variables either have a local or global (exported)
> scope.  Initially all new added variables have the local scope.  By
> using the export command they can be made global.
>
> Some variables have a special purpose and will be created by GRUB.
> These are:
>
> - root: The active disk/partition (rw, global)
> - prefix: The pathname used to load grub.cfg and the modules (rw, global)
> - platform: Set to the platform, eg. EFI, IEEE1275, PCBIOS, etc. (ro,
> global) - processor: Processor architecture GRUB was compiled for, eg. PPC,
> x86 (ro, global). - debug: Print debugging messages for certain parts of
> the code, or all messages when set to all.  (rw, global?)
> - pager: When set to `1', wait for a key when the bottom of the screen was
> reached.

BTW the Intel's EFI Shell uses an option to a command to enable a pager. This 
way might be more convenient than a variable. Or a pipe? I think a pipe 
sounds overkill, though.

> ============
> Menu entries
> ============
>
> Menu entries are added with `menuentry' (or its alias `@').  It's
> important to notice this is not a command.  Because it's part of the
> scripting syntax, it can have unique features.  A menuentry is like a
> function, especially because it can have arguments!
>
> Syntax: menuentry "Entry name" [arguments...] { body }
>
> Make sure the entry name is properly escaped, otherwise spaces can not
> be included and will be seen as separator.  The arguments will become
> semi-variables like #1, #2, etc.  These can be used so one menuentry
> can be used as a template for a lot of menuentries.  This can best be
> explained with an example:
>
> (inside loop that sets i = 1...x)
> @ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
>
> This will set #1 to $i (it's the first argument).  The menuentry
> command is executed for i=1...9 and will generate 9 different menu
> entries.  This is useful for automatic generation of menu entries.
>
> ==> Currently unimplemented: Arguments for automatic generation of
>     menuentries.
> ==> Discussion: Perhaps I will change the #1 into $1, although this is
>     not really a variable.

As I said before, menu entries are a special type of functions. So the 
arguments must be passed as $1, $2, etc.

> =====
>  for
> =====
>
> The for command can be used to iterate over a set of data.  I don't
> like the idea of implementing this *exactly* like in bash.  Personally
> I am thinking of the following syntax:
>
> Iterating over files:
> for x in (hd0,3)/foo/* ; do commands ; done

How is this different from BASH? The asterisk is interpreted as a wildcard, 
and this is not a part of "for" in BASH.

> ================
>  Error handling
> ================
>
> Every command can return an error value.  This error value will be
> available as $?.  This variable will be checked by if, while, etc.  In
> scripts all parsing errors will be non fatal so the system is not left
> unbootable.
>
> Unparsable menu entries will be added, but will not be executable,
> only the editor is available.
>
> One special purpose variable $ERROR will be added.  It will contain
> the error strings when $? is set to non-zero.  In that case you can do
> error handling in scripts.
>
> After every command an error is printed by default.  You don't want
> this to be silent, otherwise users can not detect errors.  But it
> should be able to set error handling to silent because a certain
> script or function does its own error handling.  This can be done by
> setting $ERRORS=0 (default it is set to 1).
>
> ==> Currently unimplemented: $ERROR, $ERRORS, a lot of this logic is
>     far from perfect.

This sounds too much for me. How about supporting a subset of "set" in BASH? 
For example, set -d and set +d. The default can be set -d.

Okuji

Re: Scripting (IMPORTANT!)

[Marco Gerards]

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

> On Thursday 05 October 2006 15:41, Marco Gerards wrote:
>> It's also one of the features that we all have to talk about before we
>> determine it will not be changed.  After GRUB 2 is being used by
>> everyone it will be hard, if not impossible, to make changes that make
>> different GRUB 2 versions incompatible.
>
> I agree. And I believe that GRUB should follow BASH whenever reasonable, so 
> that the user does not have to learn new things only for GRUB. Inventing a 
> new syntax is something I dislike. Also, I believe that one should write a 
> new module if she wants another language in GRUB, and execute it by a 
> command, as in GNU.

Great.  It is easy to add a new parser and bits and pieces of the
AST.  So adding another language should be easy by design.

>> Another thing I want to discuss soon is using "cd" and "pwd" commands
>> to change the current directory instead of what we have now.  I would
>> like to make this change as well.
>
> I thought the same thing before, but I didn't, because the effect of setting 
> the root device has a different meaning, that is, to set a boot device for 
> the chainloader. Besides this, the root variable is very similar to the 
> concept of "current working directory" in Unix. So I wouldn't object 
> strongly, even if you change it this way.

I think it makes more sense when scripting.  I also think it is easier
for users to deal with.

[...]

>> - pager: When set to `1', wait for a key when the bottom of the screen was
>> reached.
>
> BTW the Intel's EFI Shell uses an option to a command to enable a pager. This 
> way might be more convenient than a variable. Or a pipe? I think a pipe 
> sounds overkill, though.

Well, I made this a variable because we wanted variables instead of
commands when possible.

>> ============
>> Menu entries
>> ============
>>
>> Menu entries are added with `menuentry' (or its alias `@').  It's
>> important to notice this is not a command.  Because it's part of the
>> scripting syntax, it can have unique features.  A menuentry is like a
>> function, especially because it can have arguments!
>>
>> Syntax: menuentry "Entry name" [arguments...] { body }
>>
>> Make sure the entry name is properly escaped, otherwise spaces can not
>> be included and will be seen as separator.  The arguments will become
>> semi-variables like #1, #2, etc.  These can be used so one menuentry
>> can be used as a template for a lot of menuentries.  This can best be
>> explained with an example:
>>
>> (inside loop that sets i = 1...x)
>> @ "Partition $i" $i { linux /vmlinuz root=/dev/hda#{1} }
>>
>> This will set #1 to $i (it's the first argument).  The menuentry
>> command is executed for i=1...9 and will generate 9 different menu
>> entries.  This is useful for automatic generation of menu entries.
>>
>> ==> Currently unimplemented: Arguments for automatic generation of
>>     menuentries.
>> ==> Discussion: Perhaps I will change the #1 into $1, although this is
>>     not really a variable.
>
> As I said before, menu entries are a special type of functions. So the 
> arguments must be passed as $1, $2, etc.

Well, $1, $2, etc makes more sense to me as well.  But it doesn't
describe what really happens, although the user might not be concerned
with this.  I will start a discussion on this if it causes problems.

>> =====
>>  for
>> =====
>>
>> The for command can be used to iterate over a set of data.  I don't
>> like the idea of implementing this *exactly* like in bash.  Personally
>> I am thinking of the following syntax:
>>
>> Iterating over files:
>> for x in (hd0,3)/foo/* ; do commands ; done
>
> How is this different from BASH? The asterisk is interpreted as a wildcard, 
> and this is not a part of "for" in BASH.

You removed the relevant context.  Right, GRUB has no wildcard.  I
don't really understand what you mean.

>> ================
>>  Error handling
>> ================
>>
>> Every command can return an error value.  This error value will be
>> available as $?.  This variable will be checked by if, while, etc.  In
>> scripts all parsing errors will be non fatal so the system is not left
>> unbootable.
>>
>> Unparsable menu entries will be added, but will not be executable,
>> only the editor is available.
>>
>> One special purpose variable $ERROR will be added.  It will contain
>> the error strings when $? is set to non-zero.  In that case you can do
>> error handling in scripts.
>>
>> After every command an error is printed by default.  You don't want
>> this to be silent, otherwise users can not detect errors.  But it
>> should be able to set error handling to silent because a certain
>> script or function does its own error handling.  This can be done by
>> setting $ERRORS=0 (default it is set to 1).
>>
>> ==> Currently unimplemented: $ERROR, $ERRORS, a lot of this logic is
>>     far from perfect.
>
> This sounds too much for me. How about supporting a subset of "set" in BASH? 
> For example, set -d and set +d. The default can be set -d.

What do you mean by "this"?  I assume you mean -e instead of -d?  I
hope you can check what you really mean, a -d does not exist.

--
Marco

Re: Scripting (IMPORTANT!)

[Yoshinori K. Okuji]

On Friday 13 October 2006 21:52, Marco Gerards wrote:
> > I thought the same thing before, but I didn't, because the effect of
> > setting the root device has a different meaning, that is, to set a boot
> > device for the chainloader. Besides this, the root variable is very
> > similar to the concept of "current working directory" in Unix. So I
> > wouldn't object strongly, even if you change it this way.
>
> I think it makes more sense when scripting.  I also think it is easier
> for users to deal with.

I don't know. I leave the decision to you.

> > BTW the Intel's EFI Shell uses an option to a command to enable a pager.
> > This way might be more convenient than a variable. Or a pipe? I think a
> > pipe sounds overkill, though.
>
> Well, I made this a variable because we wanted variables instead of
> commands when possible.

Exactly.

> Well, $1, $2, etc makes more sense to me as well.  But it doesn't
> describe what really happens, although the user might not be concerned
> with this.  I will start a discussion on this if it causes problems.

I guess this wouldn't be a big problem, since most users wouldn't use this 
feature.

> >> =====
> >>  for
> >> =====
> >>
> >> The for command can be used to iterate over a set of data.  I don't
> >> like the idea of implementing this *exactly* like in bash.  Personally
> >> I am thinking of the following syntax:
> >>
> >> Iterating over files:
> >> for x in (hd0,3)/foo/* ; do commands ; done
> >
> > How is this different from BASH? The asterisk is interpreted as a
> > wildcard, and this is not a part of "for" in BASH.
>
> You removed the relevant context.  Right, GRUB has no wildcard.  I
> don't really understand what you mean.

I meant that the asterisk is not a part of a description for "for".

> > This sounds too much for me. How about supporting a subset of "set" in
> > BASH? For example, set -d and set +d. The default can be set -d.
>
> What do you mean by "this"?  I assume you mean -e instead of -d?  I
> hope you can check what you really mean, a -d does not exist.

Oops. Yes, I meant -e instead.

Okuji

Re: Scripting (IMPORTANT!)

[Marco Gerards]

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

>> >> =====
>> >>  for
>> >> =====
>> >>
>> >> The for command can be used to iterate over a set of data.  I don't
>> >> like the idea of implementing this *exactly* like in bash.  Personally
>> >> I am thinking of the following syntax:
>> >>
>> >> Iterating over files:
>> >> for x in (hd0,3)/foo/* ; do commands ; done
>> >
>> > How is this different from BASH? The asterisk is interpreted as a
>> > wildcard, and this is not a part of "for" in BASH.
>>
>> You removed the relevant context.  Right, GRUB has no wildcard.  I
>> don't really understand what you mean.
>
> I meant that the asterisk is not a part of a description for "for".

It's good you mention this, because it's exactly the discussion I want
to start.  The question here is: How do we want to deal with the
`for'?

In bash it iterates over all arguments.  The wildcards are expanded by
the shell and thus it just has a look at its arguments.  The question
here is, do we want to deal with wildcards?  It makes the code more
complex and I think there is little gain.

For GRUB I think some kind of iterators are more useful.  In that case
you can write a module to iterate over certain data.  For example over
files, disks, partitions, terminals or whatever.  It leaves the bash
syntax, but it is more useful in our case and modular.

>> > This sounds too much for me. How about supporting a subset of "set" in
>> > BASH? For example, set -d and set +d. The default can be set -d.
>>
>> What do you mean by "this"?  I assume you mean -e instead of -d?  I
>> hope you can check what you really mean, a -d does not exist.
>
> Oops. Yes, I meant -e instead.

Great!  Thanks.  I didn't know about "set -e", so I am happy you
mentioned it.  I will add this feature to our set.

--
Marco

Re: Scripting (IMPORTANT!)

[Yoshinori K. Okuji]

On Friday 13 October 2006 23:03, Marco Gerards wrote:
> It's good you mention this, because it's exactly the discussion I want
> to start.  The question here is: How do we want to deal with the
> `for'?
>
> In bash it iterates over all arguments.  The wildcards are expanded by
> the shell and thus it just has a look at its arguments.  The question
> here is, do we want to deal with wildcards?  It makes the code more
> complex and I think there is little gain.
>
> For GRUB I think some kind of iterators are more useful.  In that case
> you can write a module to iterate over certain data.  For example over
> files, disks, partitions, terminals or whatever.  It leaves the bash
> syntax, but it is more useful in our case and modular.

If you make this feature only for "for", the behavior would be not intuitive 
for the user. For instance, if "echo" does not interpret wildcards, we would 
hear the same question, "Why doesn't this work?", again and again. Also, It 
sounds really ugly to interpret wildcards in each command.

Okuji

Re: Scripting (IMPORTANT!)

[Marco Gerards]

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

> On Friday 13 October 2006 23:03, Marco Gerards wrote:
>> It's good you mention this, because it's exactly the discussion I want
>> to start.  The question here is: How do we want to deal with the
>> `for'?
>>
>> In bash it iterates over all arguments.  The wildcards are expanded by
>> the shell and thus it just has a look at its arguments.  The question
>> here is, do we want to deal with wildcards?  It makes the code more
>> complex and I think there is little gain.
>>
>> For GRUB I think some kind of iterators are more useful.  In that case
>> you can write a module to iterate over certain data.  For example over
>> files, disks, partitions, terminals or whatever.  It leaves the bash
>> syntax, but it is more useful in our case and modular.
>
> If you make this feature only for "for", the behavior would be not intuitive 
> for the user. For instance, if "echo" does not interpret wildcards, we would 
> hear the same question, "Why doesn't this work?", again and again. Also, It 
> sounds really ugly to interpret wildcards in each command.

Ok, that sounds sane.  But it does not address my problem.  How would
one iterate over disks and partitions.  And perhaps other things like
loaded modules, etc.  Personally I do not care a lot about syntax, but
I want the language to be full features so most end users can do what
they want.

--
Marco

Re: Scripting (IMPORTANT!)

[Yoshinori K. Okuji]

On Saturday 14 October 2006 17:43, Marco Gerards wrote:
> Ok, that sounds sane.  But it does not address my problem.  How would
> one iterate over disks and partitions.  And perhaps other things like
> loaded modules, etc.  Personally I do not care a lot about syntax, but
> I want the language to be full features so most end users can do what
> they want.

A naive way is "(*)" and "(*,*)". But I guess you had this in mind.

Okuji