grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting (IMPORTANT!)


From: Yoshinori K. Okuji
Subject: Re: Scripting (IMPORTANT!)
Date: Fri, 13 Oct 2006 21:32:11 +0200
User-agent: KMail/1.8.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]