From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1ETJtw-0004J7-49 for mharc-grub-devel@gnu.org; Sat, 22 Oct 2005 09:59:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ETJtu-0004J0-Dl for grub-devel@gnu.org; Sat, 22 Oct 2005 09:59:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ETJts-0004Il-HD for grub-devel@gnu.org; Sat, 22 Oct 2005 09:59:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ETJtr-0004Ie-AU for grub-devel@gnu.org; Sat, 22 Oct 2005 09:59:07 -0400 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ETJtr-0005YX-Dr for grub-devel@gnu.org; Sat, 22 Oct 2005 09:59:07 -0400 Received: from vscan-cn.han.nl (venus.han.nl [145.74.65.6]) by mail-cn.han.nl (Postfix) with ESMTP id 65E098671 for ; Sat, 22 Oct 2005 15:59:06 +0200 (CEST) Received: from mail-cn.han.nl ([145.74.66.11]) by vscan-cn.han.nl (venus.han.nl [145.74.65.6]) (amavisd-new, port 10024) with ESMTP id 26856-05 for ; Sat, 22 Oct 2005 15:59:05 +0200 (CEST) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id 88EFA829E for ; Sat, 22 Oct 2005 15:59:05 +0200 (CEST) Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id 545F1C046 for ; Sat, 22 Oct 2005 15:59:05 +0200 (CEST) Mail-Copies-To: metgerards@student.han.nl To: grub-devel@gnu.org From: Marco Gerards Date: Sat, 22 Oct 2005 15:59:05 +0200 Message-ID: <87pspxtzyu.fsf@student.han.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (2.2.0) at vscan-cn.han.nl Subject: Scripting support 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: Sat, 22 Oct 2005 13:59:11 -0000 Hi, Last days I have been thinking about scripting support. With my last patch it should be easy to implement. I hope Vladimir is still interested in this. The most important is the general design. I think we shouldn't put too much in the core and not even in normal mode. This is the same approach bash has taken. I think the core functionality should be: - variables (we have that) - functions Functions should work *exactly* like normal GRUB commands. In that case we can easily mix GRUB commands and functions. - Return values All commands should be able to return a value. That's also what bash has. This value can be stored in a variable or simply returned, I am not too sure about that. Just check what bash does. - Conditional statements like if and case - loops: until, while and for Whenever a command line should be executed or when a script file is executed, it's the same. The block of code is just parsed and executed by a function (the parser, I guess :)). It's important to see that GRUB does not do anything like calculations. All this can be moved into a command. When making a bash script you have the same, there is the expr command. So we have to keep the core functionality minimal and should offer the commands in command/ like we do now. First the lexer. I think it should work like this: normal/parser.c should contain the lexer. The prototypes etc. can just be added to include/grub/parser.h. There are just a few tokens we have to recognize. Think about stuff like a string of text, if, elif, case, ;, [], etc. The parser can be quite simple. It has to support all kinds of loops, etc. I am not sure how to deal with that. perhaps we have to feed the block within a for loop (for example) to the parser until the for loop exits. Another possibility is creating some kind of P-code and parse that later on. I wonder what the best approach is. For the parser we should use bison, I think. Writing a handwritten parser is acceptable if some standard approach is taken and it's really really clean and well documented. Any idea is welcome. I hope we can discuss the implementation in detail so we can have scripting support soon. Thanks, Marco