"Yoshinori K. Okuji" <[EMAIL PROTECTED]> 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel