Marco Gerards wrote:
Serbinenko Vladimir <[EMAIL PROTECTED]> 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
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/grub-devel
