From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1D0Pxv-0000DA-2j for mharc-grub-devel@gnu.org; Sun, 13 Feb 2005 15:03:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D0PrG-0007qc-Dw for grub-devel@gnu.org; Sun, 13 Feb 2005 14:56:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D0Pqv-0007hX-K1 for grub-devel@gnu.org; Sun, 13 Feb 2005 14:56:22 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D0Pqv-0007gM-5n for grub-devel@gnu.org; Sun, 13 Feb 2005 14:56:21 -0500 Received: from [194.67.23.122] (helo=mx2.mail.ru) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D0PaQ-0003qc-3f for grub-devel@gnu.org; Sun, 13 Feb 2005 14:39:18 -0500 Received: from [62.202.54.79] (port=1550 helo=[192.168.1.100]) by mx2.mail.ru with esmtp id 1D0PaL-000EA2-00 for grub-devel@gnu.org; Sun, 13 Feb 2005 22:39:14 +0300 Message-ID: <420FAD04.9090401@list.ru> Date: Sun, 13 Feb 2005 20:39:48 +0100 From: Serbinenko Vladimir User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: The development of GRUB 2 References: <20050207121011.GC1380@mjk.myfqdn.de> <42077EA1.5090403@list.ru> <200502081420.43561.okuji@enbug.org> <4208E717.9040205@list.ru> <87650yonaj.fsf@marco.marco-g.com> <420D2B3B.9040702@list.ru> <87ekfkthkf.fsf@marco.marco-g.com> In-Reply-To: <87ekfkthkf.fsf@marco.marco-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected Subject: Re: Scripting 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: Sun, 13 Feb 2005 20:03:33 -0000 Marco Gerards wrote: >Serbinenko Vladimir writes: > > > >>>- Why does everything happen with strings? >>> >>> >>> >>Because environment variables are the strings and it's not really >>needed to convert them (excluding the calculating) >> >> > >Personally I don't like it too much. I prefer keeping such >information in a struct or so. You could how it in a string, but in >that case I would not use string operations that much. > > > I also but every laguage uses the variables. In our case they are in environment >>>- Why are that many functions duplicated? (for example >>> grub_bash_dupstr). >>> >>> >>> >>> >>> >>In this case I just forgot about grub_strdup. But some other functions >>have (nerly) the same names that string function but are adapted for >>scripting (ex: grub_bash_strchr) >> >> > >What is the difference with grub_strchr and grub_bash_strchr? The >names give me the impression they are similar. > > grub_bash_strchr doen't consider characters that are quoted, escaped or in brackets >One this about the `grub_bash_' prefix. I think it is a bit confusing >because the syntax is bash like, it is not bash. I would prefer a >grub_script_ or grub_scripting_ prefix. > > > As you want. Anyway it's easy to change by simple replacing and it has no importance for me >>>- What is that huge table with operators? >>> >>> >>> >>It's used to determinate which operator to execute (see >>grub_bash_find_oper and grub_bash_eval_arith) >> >> > >Ok. > > > >>>What kind of parser is it? >>> >>> >>> >>> >>It's a direct parser with aritmetic subparser. Main parser is >>grub_bash_execute, arithmetic subparser is grub_bash_eval_arith. >>grub_bash_execute determinates the special cases (loops,conditions, >>functions,...) for other cases (commands,assignments, function calling) >>it calls grub_bash_split_tokens, grub_bash_expand_braces and >>grub_bash_expand_dollar >> >> >> >>> I have never seen this in a top-down or bottom-up parser I have >>> studied. >>> >>> >>I don't like to write the things reffering every time to algorithm. >>Genereally I take some ideas and I write myself, at my own. >> >> > >What do you mean? > >The problem is that I like proven concepts. And when you use a >commonly known parser design many people will be able to understand >it. To me this is REALLY important. I wonder what other developers >think of that. > > > I use proven concepts as base but then I adapt them >>>So can you explain what >>> happens when executing a script? First you load the file. Do you >>> parse it, make pcode of it, run it directly? >>> >>> >>> >>For the files I use grub_bash_exec_file. Only thing it does is >>reading a file line by line and calling grub_bash_execute >> >> > >So you run it while parsing, ok. > > > >>> How about error >>> handling? >>> >>> >>> >>For now the problem is that not all posiible syntax errors are handled >>correctly and more return checks have to be written. But first I'll write >>line counting (only grub_bash_execute, grub_bash_list_execute and >>grub_command_execute are affected) >> >> > >Ok. Error handling is often not implemented in small parsers because >it can be really hard. Don't forget error handling is really >important. Syntax errors should not make the parser crash, hang, >etc. Producing the right error and handling it right so GRUB remains >in a valid state, etc is a difficult task, I think. > > > Not with bash because in many constructions (except loops, conditions and arithmetic) when some structure is not valid it just lefts it unchanged (consider like a string or a command) >Thanks, >Marco > > > >_______________________________________________ >Grub-devel mailing list >Grub-devel@gnu.org >http://lists.gnu.org/mailman/listinfo/grub-devel > > > >