From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GYSx5-00022v-TJ for mharc-grub-devel@gnu.org; Fri, 13 Oct 2006 15:44:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GYSx4-00020n-LT for grub-devel@gnu.org; Fri, 13 Oct 2006 15:44:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GYSx3-0001xf-9R for grub-devel@gnu.org; Fri, 13 Oct 2006 15:44:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GYSx3-0001x9-3c for grub-devel@gnu.org; Fri, 13 Oct 2006 15:44:13 -0400 Received: from [194.109.24.29] (helo=smtp-vbr9.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GYT5Y-0000o9-0A for grub-devel@gnu.org; Fri, 13 Oct 2006 15:53:00 -0400 Received: from localhost.localdomain (249-174.surfsnel.dsl.internl.net [145.99.174.249]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id k9DJi9qF044324 for ; Fri, 13 Oct 2006 21:44:10 +0200 (CEST) (envelope-from mgerards@xs4all.nl) From: Marco Gerards To: The development of GRUB 2 References: <87fye2swwa.fsf@xs4all.nl> <200610132132.11614.okuji@enbug.org> Mail-Copies-To: mgerards@xs4all.nl Date: Fri, 13 Oct 2006 21:52:43 +0200 In-Reply-To: <200610132132.11614.okuji@enbug.org> (Yoshinori K. Okuji's message of "Fri, 13 Oct 2006 21:32:11 +0200") Message-ID: <87d58wro1g.fsf@xs4all.nl> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: Scripting (IMPORTANT!) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Oct 2006 19:44:14 -0000 "Yoshinori K. Okuji" 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