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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
