Re: Scripting

[Serbinenko Vladimir]

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
> > > 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>
>