[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting

From: Serbinenko Vladimir
Subject: Re: Scripting
Date: Sun, 13 Feb 2005 20:39:48 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

Marco Gerards wrote:

Serbinenko Vladimir <address@hidden> 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

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)


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

I have never seen this in a top-down or bottom-up parser I have
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

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)


Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]