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