Re: Scripting (IMPORTANT!)

[Marco Gerards]

"Yoshinori K. Okuji" <address@hidden> 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